Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 17, 2013 11:33 UTC (Tue) by mathstuf (subscriber, #69389)
In reply to: Another daemon for managing control groups by dlang
Parent article: Another daemon for managing control groups

OK, so in this case, how does systemd manage cgmanager? Cgroups is out since cgmanager hasn't started. Or systemd has special logic for cgmanager. But then why have the logic in two places? Plus, cgmanager would probably end up as PID 2(ish)[1]. Sorry, I don't see how making systemd ask anything else about cgroups when it is such a core mechanism makes the overall system simpler and cleaner.

[1]Or 3; journald is pretty early too...but what is more important: logs or management? If logs, there's another thing that needs special group logic. Wait, cgmanager is over DBus, so add dbus-daemon to the list. What's the saying? "Do something once, hack it out; twice, use history; thrice, write a goddamn script" (or something). So if systems has special code to put the journal, DBus (modulo kdbus), and cgmanager, why the hell would you not just put all the logic in systemd to start with?

to post comments

Another daemon for managing control groups

Posted Dec 17, 2013 13:23 UTC (Tue) by Jonno (guest, #49613) [Link] (8 responses)

Without having written any prototype code, but only looked at the problem architecturally, I agree that pushing cgroup management out of PID 1 will likely require *more* code in PID 1 than simply doing the cgroups management directly in systemd in the first place. But even so you don't need to drag dbus-daemon into the picture. cgmanager could use the same trick as systemd does, and initially only listen on a private socket for root-only direct libdbus communication, and then register itself on the dbus-daemon system bus whenever it becomes available.

That way cgmanager can start as PID 3 (after only systemd and journald), and the only early boot special handling in PID 1 would be to first start journald and cgmanager and then add them to their respective cgroups after the fact, but before continuing with any other units. Obviously that adds a bit of serialisation before going of and doing everything else in parallel, so will likely increase boot time by a second or two, but it's not like getting it to work is rocket science.

The trickier question is how to deal with cgmanager dying unexpectedly. PID 1 enjoys a privileged position and the kernel makes sure it never ever dies for any reason whatsoever, but PID 3 has no such protection. If systemd depends on it to do regular service management, it can't just restart cgmanager like it does any other service. Instead it would need special recovery code for that rare-but-inevitable case, code that likely won't get much testing, a perfect recipe for eventual disaster...

Another daemon for managing control groups

Posted Dec 17, 2013 18:07 UTC (Tue) by hummassa (guest, #307) [Link] (7 responses)

> PID 1 enjoys a privileged position and the kernel makes sure it never ever dies for any reason whatsoever

AFAICT the kernel dies and locks the machine out if PID 1 dies.

Another daemon for managing control groups

Posted Dec 17, 2013 18:14 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I think it "just" panics. At that point, PID numbers are pretty useless I'd think :) .

Systemd's behavior in the face of a fatal error is to enter an infinite loop rather than dying[2].

[1]http://cgit.freedesktop.org/systemd/systemd/tree/src/core...
[2]http://cgit.freedesktop.org/systemd/systemd/tree/src/shar...

Another daemon for managing control groups

Posted Dec 17, 2013 19:23 UTC (Tue) by Jonno (guest, #49613) [Link]

> AFAICT the kernel dies and locks the machine out if PID 1 dies.
The kernel will panic if PID 1 exits on its own, but it will protect it from all outside interference (including blocking the normally unblockable SIGKILL and SIGSTOP), so as long as you handle all normal signals and never call exit() or return from main() you are golden.

As noted above systemd will enter an infinite loop (always yielding it's time slot back to the scheduler as to not monopolize the CPU) in the signal handler for any error signal it can't handle more gracefully, but that is only to protect from internal bugs, and not a normal operational condition, which a dying cgmanager would be.

Another daemon for managing control groups

Posted Dec 18, 2013 9:45 UTC (Wed) by anselm (subscriber, #2796) [Link] (4 responses)

The kernel won't lock the machine if PID 1 dies; it will complain but keep running by itself.

The legend goes that there used to be people whose PID 1 would set up a bunch of iptables rules and associated config and then exit – which would give you a firewall/router that was absolutely free from outside interference if a bit inconvenient to manage.

Another daemon for managing control groups

Posted Dec 18, 2013 15:14 UTC (Wed) by raven667 (guest, #5198) [Link]

I've had that happen, but not intentionally 8-) I've had devices too where the block device died but everything that was commonly used an in RAM/cache was still accessible, that machine actually ran for a year or two in that state doing its job before it could be decommissioned.

Another daemon for managing control groups

Posted Dec 18, 2013 18:33 UTC (Wed) by dlang (guest, #313) [Link]

I did that once, as much to show I could as anything else.

Another daemon for managing control groups

Posted Jan 17, 2014 10:27 UTC (Fri) by etienne (guest, #25256) [Link] (1 responses)

> ... let PID 1 exit to have a secure router ...

I have a new question to an old answer, to secure a system after it has been correctly configured:
Can you get rid of /bin/sh (i.e. any sort of shell: bash, ksh, zsh...) and still have a booting computer if you use systemd?
That would be very difficult to try to compromise a computer if the shell has been removed...

Another daemon for managing control groups

Posted Jan 17, 2014 10:36 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, it's absolutely possible to boot a computer without any shell using systemd.