Adam Borowski - 08.08.17, 18:57:
> On Tue, Aug 08, 2017 at 11:53:56AM -0400, Steve Litt wrote:
> > Be careful recommending cgroups.
> >
> > I've never used them, and know little about them, but I know they were
> > one of the main excuses for systemd.
>
> Uhm, what? Systemd uses ELF objects too, should we go with a.out for this
> reason?
>
> cgroups are a way to say "this group of processes may not use more than 2GB
> memory". How else would you ensure a misbehaving set of daemons / container
> /etc does not bring down the rest of the system with it?

I agree that cgroups can be a useful feature. Yet… also a bit clumsy to use,
and not free of race conditions. That written, kernel developers are working
to fix part of the clumsyness and completely and all of the race conditions by
unifying all cgroup controllers (memory, cpu and so on) in one directory tree.

> Systemd usurps to be the only user of this facility, but if you don't suffer
> from systemd infestation, nothing keeps you from doing so yourself. In
> fact, it works far better without systemd: unless it was fixed while I
> wasn't looking, because of the way systemd sets it up, you can't use
> cgroups in a container unless that container's systemd talks to the host's
> systemd -- which is fragile, requires that both are infested, that both use
> a compatible version, and using a different distribution or architecture
> makes it no go. I for one run a bunch of amd64, i386 and x32 containers
> that range from wheezy to unstable, and all is fine. Ok, I guess I'd have
> problems running systemd inside, but I can accept _this_ retriction.

Also I still not completely get *how* it actually sets it up.

But there are further issues. Systemd is completely tied to cgroups as the
only means to control processes. Thats part of the reason why Systemd is not
portable.

I know Systemd developers argued countless of times, that it would not be
possible to separate out the cgroup handling into another process than PID 1,
but even if thats a case… why not allow different in process modules to handle
service supervision. And why not limit the usecase of PID 1 to exactly that,
being an init system that starts services and supervises them.

But on the other hand… I still not get… why it would not to have each service
started by new child process of PID 1, that sets up cgroup limits and
supervises the service process… so that PID 1 just has to supervise that child
process and react when it sends a signal or exits. This sounds a bit like the
approach runit is using, but AFAIK runit´s runsv doesn´t support control
cgroups.

What I see is that Systemd PID 1 gets larger and larger and larger (Debian
Sid):

% ls -l /lib/systemd/systemd
-rwxr-xr-x 1 root root 1514528 Jul 20 15:13 /lib/systemd/systemd

It has been almost 200 KiB less with Debian 8:

% ls -l /lib/systemd/systemd
-rwxr-xr-x 1 root root 1313160 Apr 8 23:08 /lib/systemd/systemd

Sysvinit´s init process was just about 40 KiB.

Thanks,
--
Martin