Poettering: The Biggest Myths

There is an example of how this can work, although with less features and guarantees (no cgroups, no dependancies), with daemontools. You run the svscan daemon out of /etc/inittab which maintains a parent/child relationship and pipe with PID 1 so that it can be restarted should it fail and svscan fires off a separate supervise process for each daemon you want to manage. supervise maintains a parent/child relationship and pipe with its child process and will restart the child should it go away. If there is a log startup script then that is run as well and anything written to the childs stdout or stderr is forwarded to the stdin of the log daemon (usually multilog).

You can hack around many of the failures (lack of restart throttling for example by using sleep) but it's not feasible to hack around the lack of service dependency resolution and the fact that this is an add-on component and not part of the core OS so can't be relied upon to be there in most cases. There has been development and thought in the area of service management beyond SysV init in the last 15 years or so but there are real reasons why these systems like daemontools and runit haven't gained the traction that systemd has gained, because they are not as comprehensive and are technically inferior.