Well, there's something to be said for daemontools which insists you set up a properly managed service namespace as opposed to going towards the convenient but limited route of the quick fix. I still don't see how "svc -u" is more complicated than "systemctl start", though.
That said, I would definitely not characterize systemd as "just works". Besides the issues that come with its intertwining system state, service state, process management, process supervision, configuration parsing and so on all in one critical process, the unit file mechanism is significantly less expressive than the chain loading mechanism (which really shines when used with a small dedicated lexer for run scripts like execline). You are limited within the bounds of the INI key pairs and you have no way to compose them, because they're just fixed entries in a hash table that systemd sets up at build time to look up.
The dependency mechanism is a quagmire of its own, with it mixing up semantics between ordering and dependence while limiting the service relationship types to whatever the systemd toolkit gives you. It introduces the problem of dependency loops which barely give you any debugging context when they occur, and it requires that systemd maintain complicated internal job and transaction consistency checking for a dependency system which will fundamentally always remain incomplete, because dependencies with respect to processes work entirely different compared to dependencies in libraries where you have fixed expectations of public symbols, relocated and resolved by the dynamic loader.
It feels like systemd, in the part where it's best at - service management, isn't ambitious enough. Instead it has decided to be a sprawling middleware doing 100 things and none of them completely, in an attempt to be a standard userland you just theoretically plug in between GNU and Linux and get a distro. In practice, the integration work required to maintain a systemd-compliant runtime and keep up with the rapid chaotic pace of development is not any less difficult than maintaining poorly written SysV initscripts.
Maybe my needs just aren't that exotic? I'm currently using daemontools at work and so far I have a slightly unfortunate handful of bash scripts that repeat in different projects with minor variations.
I've also used launchd (OSX) for Serious Things That I Don't Want to Fail, and it was easy. One config file with a few details. Completely watertight abstraction, as far as I could tell.
Pretty much all of the new school init systems, loosely starting from 2004 onwards (Upstart, launchd, Solaris SMF, systemd) have glaring structural deficiencies in one way or another, from my observations.
Exactly. I just want to keep a couple of processes running without having to learn the DJB ecosystem. I also want them portable if we shift off CentOS to Ubuntu in the future or something.
I'd argue that the DJB ecosystem has an almost-zero learning curve if you have a decent grasp on your systems fundamentals. As long as you understand how process handling works, the administrivia of DJB's tools is dirt simple.
It also has the odd benefit of already being cross-platform, so even if you move whole systems distributions (e.g., from Debian GNU/Linux to FreeBSD), you can still use that same knowledge there too.
Edit: Note that simple does not imply easy. Daemontools, for example, does not provide a means for doing dependency handling, so you'll actually have to engineer around that by writing a script to handle it. Same goes for bouncing things that go off the rails. Same goes for pretty much anything that does not fall strictly under the purview of starting a process and restarting it if it crashes.
That said, I would definitely not characterize systemd as "just works". Besides the issues that come with its intertwining system state, service state, process management, process supervision, configuration parsing and so on all in one critical process, the unit file mechanism is significantly less expressive than the chain loading mechanism (which really shines when used with a small dedicated lexer for run scripts like execline). You are limited within the bounds of the INI key pairs and you have no way to compose them, because they're just fixed entries in a hash table that systemd sets up at build time to look up.
The dependency mechanism is a quagmire of its own, with it mixing up semantics between ordering and dependence while limiting the service relationship types to whatever the systemd toolkit gives you. It introduces the problem of dependency loops which barely give you any debugging context when they occur, and it requires that systemd maintain complicated internal job and transaction consistency checking for a dependency system which will fundamentally always remain incomplete, because dependencies with respect to processes work entirely different compared to dependencies in libraries where you have fixed expectations of public symbols, relocated and resolved by the dynamic loader.
It feels like systemd, in the part where it's best at - service management, isn't ambitious enough. Instead it has decided to be a sprawling middleware doing 100 things and none of them completely, in an attempt to be a standard userland you just theoretically plug in between GNU and Linux and get a distro. In practice, the integration work required to maintain a systemd-compliant runtime and keep up with the rapid chaotic pace of development is not any less difficult than maintaining poorly written SysV initscripts.