Systemd won for one simple reason: it's the only tool that accomplishes this task without bugs. We've been running daemontools for almost a decade in production, and it's a nightmare of bugs. Very glad to be finally switching to systemd.
If this is true, and speaking as a systemd user for close to five years now, it universally sucks at its primary purpose.
Specifically, whenever a service fails, I've lost count of the number of times systemd has barked out useless errors with 200 lines that boil down to "service has entered failed state". Whenever a systemd service fails, odds are better than even I have to spend two hours debugging why by enabling internal logging in that service, running in debug mode etc.
Like when I tried to switch to networkd, and had the wrong password for a wifi I was connecting to, networkd never told me this in any way I could find. Had to go back to the old solution (after an hour of pulling my hair out) before I realised the password was wrong.
networkd only springs into action when wpa_supplicant succeeds in establishing the layer 2 connection and the interface becomes UP. I like the wpa_supplicant+networkd combo precisely because of this decoupling between network layers. One day, I'll get off my lazy ass and replace NetworkManager by wpa_supplicant+networkd on my notebook.
If you want a network manager that does know about those and might give more helpful error messages if they fail, use for example NetworkManager.
repeat after me:
everything eventually fails.
How can you tell when a programmer has graduated from "completely new at this" to "has some valuable experience"? That point comes when they stop assuming success.
Check for error and do something useful with the returned value.
Write tests yourself.
Fail gracefully.
Log status, so you know what was happening just before it failed.
Set reasonable timeouts on external processes.
Systemd is written from the perspective of a laptop user who will hand over the whole thing to a support tech when things go wrong. This is antithetical to the spirit of UNIX, which is not "write programs with one purpose that chain together well".
The spirit of UNIX is this: At any time, a user on the system may decide to become a developer or a sysadmin. The tools and information they need should be available.
Or actually all of them (including networkd) work fine, but are not the right tool for every usecase.
So basically, you're saying that systemd et al integrate with everything on my system, except for when it's useful?
Not that different from other tools like `ifupdown`, `NetworkManager`, `wicd`, `connman`, ...
Hint: Networkd doesn't run wpa_supplicant. So it can't "hide" anything about it. Or only as much as `ifconfig` "hides" errors from wpa_supplicant.
I've also used runit (which follows the daemontools model) as a service manager and I've never had an issue with that. I may just have been lucky though.
For me systemd fails because of some bugs I have repeatedly experienced: - systemd stops reaping zombies for some reason; the OS's PID table becomes full and it's impossible to create new processse -> need to hard reset the machine - systemd overtakes halt/reboot commands which is ok when it works I guess -- but for some reason I sometimes get "operation timed out" (likely because of some bug in systemd or dbus). At this point I have to hard reset the machine to get back to a usable OS.
Imagine if #2 happens to you on a remote machine. In my case, I had to call someone and ask them to reset the machine.
#1 is unthinkable for me, because it's the second thing init is supposed to do (the first one being bringing up the various services). I've never had this happen to me on older Linux or other Unices because let's face it, it's not that hard to do. At that point I honestly thought "how can I expect systemd to provide all the features it boasts when it can't do the easy things well ?".
I've also had daemons that systemd lost track of, apparently because of a wrong setting in the .service file. Now that's not a systemd bug, but it was very difficult to debug because I couldn't "trace" the process starting. On the other hand, with daemontools/runit it's quite simple: manually execute the ./run script and see where it fails. With classical init, run the /etc/init.d/service with sh -x and you see exactly where it fails.
# echo b > /proc/sysrq-trigger
I've been running runit in production for many years, and it does just this, flawlessly.
Here you have a daemon that ties into PAM that tries to second guess the kernel regarding what constitutes a session.
Effectively systemd is becoming something akin to Android. It may be using the Linux kernel, but it is not the GNU/Linux we have grown familiar with over the years.
It has some sort of sessions for processes, but that is just something sharing the same name, not the same concept.