systemd's unique benefits (if any)

Posted Oct 16, 2014 20:16 UTC (Thu) by anselm (subscriber, #2796)
In reply to: systemd's unique benefits (if any) by ksandstr
Parent article: On the sickness of our community

However a quick `pidof` and a check of the PID file dropped by start-stop-daemon (or the service process itself) should reveal whether the process is up or not, which is all that systemd's "hey I'm up" library call does.

pidof and PID files can have nasty race conditions, and in particular you can't really trust a PID file from start-stop-daemon (this is documented as a last-resort type of approach for services which don't write their own PID files, and even if they do it's a haphazard thing because you can't rely on the PID file to go away when the service does etc. etc.)

On the other hand, the mechanisms systemd uses to find out that a service process has terminated are a lot more robust. Note that the usual method to start a service in the background with sysvinit is for the service process to be launched from an init script, and to double-fork so that it is adopted by PID 1, at which point PID 1 has no idea what the process is or where it came from. With systemd, PID 1 can start a service process directly within its own cgroup, which affords a lot more control. (It also makes the service processes that much more easier to implement since you don't need to go through the double-fork-etc. song and dance that sysvinit requires.)

For example in a network server that spawns child processes to handle client connections there may be a systemic failure that prevents client interactions altogether but not startup of the parent.

Which is too bad in your sysvinit setup – the init script returns success, and then the next init script is started, which if it depends on the other service will also fail etc. With systemd, there is a chance that systemd's activation methods can stand in for a service that doesn't come up (e.g., by queuing up connection requests from other services), at least to a point where the system is in a state that allows debugging.

This only exchanges one category of failure (insufficient maintainer diligence) for another (software-induced lossage). I'd tend to prefer the former since the correctness of the latter should ideally be proven for all possible sets of dependencies whereas the former need only be correct for one initscript at a time.

Whatever floats your boat. I personally would rather depend on a general piece of software that has been implemented once and thoroughly debugged than on distribution maintainers who need to be relied upon to do the Right Thing over and over again. The way sysvinit requires maintainers to come up with yet another (usually subtly different) init script for every new service has nothing to do with “parsimony of design“; I'm all in favour of 10-line declarative unit files for systemd over 200-line procedural init scripts for sysvinit.

This becomes especially true once we need to change one line in the configuration of how a service is started from the distribution default – with systemd this means a two-line file under /etc/systemd for a change that will automatically remain in force across package updates, while with sysvinit this means changing the actual init script and somehow making sure that an update of the underlying package doesn't blow the change to kingdom come.

Compared to the lossage that systemd's growth of accessory dependencies and their expansion is causing, it's still my opinion that Debian's switch to systemd and packages depending on it is a grand mistake.

You're perfectly entitled to your opinion. We'll see where we stand five years from now.