[throwaway092834]

This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd.

There's a little piece of insight which seems to escape many: there is no serious technical reason why systemd must run as init. Systemd could have been written to coexist in a number of various ways following previous models, running under init and doing things for init.

Systemd is winning this war because it created the war, by conflicting with sysv init.

[krakensden]

> Systemd is winning this war because it created the war, by conflicting with sysv init

Except Upstart also has config files instead of shell scripts. And both of them support all your old sysv init scripts. And writing the config files is so much easier to get right the first time than rolling your own goddamn shell script by default.

On a sort of related note, I have never had an interaction with daemontools that wasn't miserable. I always find the fact that it gets waved around like a bloody shirt in these discussions terrible and terrifying.

[vacri]

The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't

Systemd is winning this war because it created the war, by conflicting with sysv init.

Upstart predates Systemd, systemd just has more traction.

[krakensden]

Several of the systemd developers worked on upstart or worked on porting fedora to upstart. Lots of the design decisions- socket based activation vs event based, cgroups integration- were made because of things that were (and still are) broken in upstart.

[throwaway092834]

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.

[vacri]

well, I wouldn't call the technical conflict unnecessary - if there wasn't a need for a more featureful init system, then there wouldn't have been a motive to write a new one. As for the social conflict, that's just what you get with social groups experiencing change.

[throwaway092834]

Your assertion is strictly false. All features of this new process invocation system could be implemented without making a "new init system." That's my primary point in commenting here. It is a false dichotomy.

[mercurial]

> All features of this new process invocation system could be implemented without making a "new init system."

Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse.

If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency system working. And socket-based activation? Sysvinit is a dead end. It's the counter to "keep it simple, stupid": when you fail to capture enough information in your "simple" model, you are going to end up with more issues than if you had created a slightly more complex system.

[icebraining]

I think the point is that you could have the old init system launch systemd, which would then work as it pleased.

[vidarh]

Systemd can run without being pid 1. In fact, systemd can run without being root, and by default systemd now starts a systemd user instance when a user session is started (there's a pam module to do this), or you can run systemd with "--user".

So if anyone wants to run systemd as a process monitor like Daemontools, separate from pid 1, they can do so.

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.

sysv init can not do this. It can track whether or not an individual process started from inittab is still running, but for large multi-process servers this is not all that practical as a process monitoring method. Hence the proliferation of process monitoring applications.

More importantly, since there's no ordering or dependency control, I've never seen a system rely on init for process monitoring this way for all its services. In practice, a bunch of pieces gets started in the init scripts, and all monitoring ends up placed externally or you then start a process monitor like Daemontools.

The problem is that all of these process monitors depends on a relatively benign environment where they are not messed with, and where they themselves are so rock stable that they never end up orphaning the services they start.

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 (say the OOM killer runs amok after your system ran ludicrously low on memory).

When that happens, unless your app was exceedingly well written, and the vast majority of server processes I have to deal with on a daily basis are not, your process is now unmonitored and you have no good way of controlling the process other than killing it and restarting. Finding pid-files have been overwritten, or are empty (say the disk ran full too, while it was being written) and multiple instances running is a fairly common scenario.

By running as pid 1, systemd is protected against being killed. 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.

This is functionality that init does not provide, and none of the process-monitors running outside of pid 1 can provide.

It may not solve problems you have, but I've had to deal with the fallout of process monitors running outside of pid 1 more than I care to remember.

[craigyk]

It's funny you mention the systemd pam module. I just recently was configuring a new Linux mint install and enabled ldap and all of a sudden noticed logging in via the desktop or ssh would hang for over a minute. I tracked it down to the pam_systemd module. Not sure what the problem in there was though.

[throwaway092834]

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

[felixgallo]

Great comment.

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?

[chrisbolt]

runit seems to have been designed to be able to replace init: http://smarden.org/runit/replaceinit.html

[throwaway092834]

It's possible, but it's not designed to. It was designed to run under init, as a daemontools clone. Explained further here: http://smarden.org/pape/djb/daemontools/noinit.html

"In contrary to Richard Gooch, I suggest not to implement service dependencies and runlevel handling in the Unix process no 1, /sbin/init, keep it small and simple, that is why I wrote the runit package"

[Fasebook]

Thank you for your excellent insight, as I would have never considered nesting inits.