[aklug] Re: systemd - was Re: multiple distros coordinate to establish /run directory

I went back and re-read that article on LWN. I think I got confused on
how "cgroups" figured into the mix.

The first time I read it, I got the impression that sockets could be
re-used/re-purposed and that you might not necessarily know what data
was currently available on a particular socket.

I think I'll need to re-read it a couple of more times (and that stuff
about window managers vs desktops).

Every time I think I have a handle on it, the lines re-blur.

Thanks,
Jim g

On Wed, 2011-04-06 at 23:01 -0800, Arthur Corliss wrote:
> On Wed, 6 Apr 2011, Jim Gribbin wrote:
>
> > I am not trying to take sides, I am just trying to figure out what
> > systemd is. I need to know what it is before I can figure out where I
> > might stand on it.
> >
> > Correct me if I am headed down the wrong path.
> >
> > A "socket" is something akin to a socket in the wall that you connect to
> > similarly plugging an electrical cord into an electrical outlet, or an
> > ethernet cable into an rj59 outlet in the wall.
> >
> > When I plug a standard extension cord or a lamp cord into what we
> > conventionally call an electrical outlet or an Ethernet cable into an
> > rj59 outlet, I normally expect to find 115v @ 60Hz or networking signals
> > (occasionally pots) from the respective sockets.
> >
> > If I am following the general idea of systemd, something, not
> > necessarily within my control, can decide to change what is available at
> > the socket on the fly.
> >
> > How do I connect to the socket confident that I am receiving expected
> > telemetry data from from Joe in ICU and that something hasn't
> > re-purposed the socket so that it's feeding data from the hospital's
> > HVAC system? I would prefer not to give Joe the "smoke test".
> >
> > This is also the part of the concept that was making me uncomfortable.
> > It smells a lot like self modifying code. I was taught this was
> > something to be avoided. It was a long time ago that I was taught that,
> > maybe philosophies have changed over the years?
>
> That particular aspect of systemd is more like inetd (but not exactly). In
> a nutshell, it knows of all the services installed and it listens on those
> sockets itself. If another application connects to it it launches the
> applicable service and hands over the waiting client connection. It's
> basically on-demand services, but without the stateless quality of inetd,
> where the service is terminated after each request. Systemd also adds
> additional launch activation triggers, like dbus messages and more.
>
> In contrast to your example above where you're worried about Joe in ICU and
> you get HVAC data, each socket has a specific address (port # for inet
> sockets, or a path for UNIX domain sockets), and each service uses a unique
> socket. So, in practice what you're worried about doesn't normally occur,
> even under systemd.
>
> If that's all systemd did, though, I would have no objections. It's that
> mingling with automountd functionality, the kernel binary format
> augmentation, the replacement of sysvinit responsibilities, virtual console
> setup, it's the timer integration (which is likely going to lead to a full
> cron replacement), the temp file/dir life cycle management, the XDG session
> management and PAM management, kernel module management, and so on. If that
> run-on sentence from hell doesn't scare you, it should.
>
> --Arthur Corliss
> Live Free or Die

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Apr 6 23:51:48 2011