I think that's my biggest problem with shell-scripts-as-an-init-system. There's nothing inherently wrong with it, but sooner or later, the only way to correct f

I think that's my biggest problem with shell-scripts-as-an-init-system. There's nothing inherently wrong with it, but sooner or later, the only way to correct for broken or missing functionality is (to borrow your term) to add more glue. And if you want more correct behavior, you either have to wait for the distro maintainers to fix it or fix it yourself only to merge your changes back in on the next OS update. That's another thing I like about systemd. With the separation of "stock" unit files in /usr/lib and user-supplied ones in /etc/systemd, you can override the ones distributed by your OS vendor without worrying about updates breaking your changes. That's already saved me once or twice during Arch's transition from sysvinit to systemd, in fact. One thing that comes to mind is an issue I had some time back with running a proprietary service in a manner that would allow the init system to control it when it forked itself a number of times and spun up separate processes. start-stop-daemon was confused by this behavior and it required some tricks to collect the approriate PID just to be able to stop the service (I may be wrong, but I think it was the TeamSpeak 3 daemon which behaves weirdly). systemd's use of cgroups ignores this rubbish entirely, because it's effectively impossible for systemd to lose track of what processes belong to which service. Want to kill the service? No problem. Some in this thread seem convinced that systemd is a solution looking for a problem, but I suspect some of them lack experience with systemd. Or stubbornly cling to their ideals of what an init system should do. I like the unification of a supervisor-type service and the init system. It makes my job easier. And that's not even half of what systemd is capable of!