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

[FooBarWidget]

Then you have two init systems. That's even more complicated than having only systemd.

[mercurial]

I'm not sure this was the point of parent, but anyway, why would you want something like that? It's not like sysvinit has any redeeming feature, and you would still want to have systemd .service files. I could understand an argument like "/bin/systemd does too many things and ought to be split up more", but the rationale for having bad old sysvinit launch /etc/init.d/systemd.sh escapes me. Not to mention that you definitely don't want both systemd and sysvinit to attempt to launch scripts in /etc/init.d, when they don't have a .service...

[vidarh]

Say something comes along at that point and kills systemd. Now everything below it is orphaned and has init as it's new parent.

Sysv-init does not know what to do with those processes other than reap zombies.

Now you have a system full of unmonitored processes, just as without systemd, and no standardized way of restarting the services.

This is why systemd needs to run parts of its logic in pid 1 to be most compelling.

You can launch systemd without letting it be pid 1, but you lose functionality it can't provided outside it.