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

On Wed, 6 Apr 2011, Jim Gribbin wrote:

> 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.

The cgroups bit was more for the server init functionality that's embedded
in systemd. By starting up a particular service daemon within a specific
cgroup it can do better clean-up when stopping or restarting a service.
That has nothing to do with sockets themselves. It's more for services that
might spawn child processes which may try to disassociate themselves with
their parents (a daemon that forks itself and disconnects from the
controlling terminal does this). Just killing the primary PID wouldn't
catch disassociated children, but as long as they inherit the cgroup systemd
can identify them and whack them as well.

It's an imperfect system, with several gaping loopholes, but the alternative
is for systemd to code application-specific knowledge for every daemon it
needs to clean up after, which is really almost impossible.

Yet another thing systemd does that's really best left to a separate
program. While it in theory it would allow resource monitoring to prevent
DoS-type situations, plus lock contentions, etc., for malfunctioning
programs, the current implementation of cgroups makes it a) linux-specific
(no systemd for you BSD'ers), and b) unreliable. Which is why they want
enhancements to the kernel implementation of them.

Perhaps someone else here can extoll the virtues of cgroups in more depth
than I can. I don't use them.

> 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.

:-) That they do.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Thu Apr 7 00:17:10 2011