systemd's unique benefits (if any)

History has shown that "could easily" doesn't quite work out so well, and pidfiles are not something that can be relied on.

And systemd's "hey, I'm up" library call uses linux's cgroups to definitively state whether or not a process and anything it's forked are still running. It's a completely reliable mechanism that doesn't require knowledge of process names and a gajillion scripts and daemons and whatnot to get things perfectly correct each and every time. (Hate to state the obvious, but they don't)

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

Wait, you say you prefer the former, because... the latter is superior?

Experience has also shown that the former tends to crop up far more often than the latter, unless you're counting "insufficient maintainer diligence" to be a "software-induced lossage" too.

Incidentally, the latter is precisely what systemd and its unit files provide: provably correct dependencies, performed in one place rather than needing to be re-implemented in shell by every single script.

> Furthermore I'm suspicious that systemd's mechanism won't cover all possible dependencies between initscripts, leading to a situation where there's a (potentially crusty, brittle, and/or legacy-saddled) magic algorithm, a set of hand-crafted dependencies, and a policy for combining the two into something that the startup function can actually execute.

Any problem that could throw off systemd would also throw off any other system that uses static dependency trees, yes, including sysvinit. Barring that, if there's some real-world thing that systemd's dependency mechanisms can't handle, I don't think I'm going out on a limb by saying that the systemd folks would love to hear about it. (When you consider that you can generate unit files on the fly to create dynamic dependency trees, systemd is *much* more capable of dealing with those crusty, magic, phase-of-the-moon sequencing tasks)

> If nothing else this conflicts with the ideal of parsimony in design; especially since the dependency list could be generated ahead of time (e.g. by the package maintainer) with a tool that's equivalent to systemd's magic, and then stored in place of existing metadata.

That's such a good idea that someone already did it -- it's called a systemd unit file. Seriously, you're arguing for a design that systemd already implements, and quite well at that.