| systemd works somewhat ok for me, because I decided to stick to a very limited subset of the functionality it attempts to provide. 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