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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
