| "But there are technical reasons for systemd to run as init: A key feature is to precisely track whether or not a service is running or not" This is not true. Tracking a running service doesn't require being init. Any process can do it. "sysv init can not do this." Nor should it. Services running under sysV init can, however. "More importantly, since there's no ordering or dependency control" Yes, there is -- it's implemented by the rc system. It's crude, but it's also just a bunch of shell scripts and completely pluggable. The systemd logic could trivially be inserted here either in place of /etc/rc, or by something that sits directly under init and drives the rest of the process. "In practice, while Daemontools for example is well written and as stable as it can be, by virtue of running outside pid 1 it is not immune to the effects of the surrounding system. It can, and does, end up orphaning monitored processes in a variety of circumstances" Any process can daemonize away from a process manager. systemd adds cgroups for tagging or containing process trees -- this is possible under runit/daemontools and it would only take minor changes to the supervise process to instantiate the cgroup and supervise accordingly. To be clear: Any process can add cgroup support to track forked children. Solving this problem by adding cgroup support has absolutely nothing to do with becoming init. "By running as pid 1, systemd is protected against being killed." No, that is false. There is no such protection -- killing pid 1 is easy. Rather, by running as pid 1 systemd will cause a kernel panic and bring down everything with it. "By then applying cgroups it can precisely track whether or not what was spawned is still running, even if it forks more stuff. By applying this to the boot process, it can provide this functionality to everything that gets started during boot." sysV already exports most boot ordering into subprocess. It is trivial to achieve these tasks with systemd as a child of init. "This is functionality that init does not provide, and none of the process-monitors running outside of pid 1 can provide." It is true that init doesn't provide these features, nor should it. Your second statement is false -- a common misconception as I've hopefully explained. If you have any further technical questions about how one CAN perform all these actions as a child of init I would be happy to explain in detail. |
The thing that strikes me as the very weirdest about all of this is that many of the systemd proponents seem to be incredibly animated and aggressive about systemd, but most of their arguments are either non-technical or completely wrong. Like, what's the motivation? Why have so many people gotten to this mentality?