Simon Richter <s...@debian.org> writes: > In the same way, we could have had automatic restart of services through > sysvinit easily: an include mechanism that allows additional inittab > lines to be pulled from /etc/inittab.d/* would be trivial to > implement. That it hasn't been done is not because no one has thought > about it in the last thirty years, but because its use is rather > limited.
Er, well... speaking as someone who tried to keep daemons running via inittab and then gave up and tried using monit for a while, and then switched to djb daemontools (all back before systemd existed), I'm not sure this is quite right. Those who tried to use this facility quickly discovered that sysvinit was rather bad at it, and therefore started using something else. Problems included difficulty controlling respawn rates, sometimes-silent permanent termination of the service when something went wrong, no support for per-service fragments (easy to implement or not, no one implemented it), weird behavior when daemons got into a crash loop, no good way to externally control whether the service was temporarily disabled or not, problems specifying and controlling start order, weird behavior with standard input and output, and weirdness when changing the configuration. djb started daemontools via a script in inittab and suggested just rebooting the machine after initial configuration because getting init to reload its configuration properly was too unpredictable. Note that this is not a statement about Linux sysvinit specifically -- my experiences were originally on Solaris. The flaws in using inittab to keep services running were universal among UNIX implementations. systemd is *much* better at these things, as is runit, upstart, and basically every other init system that came along after sysvinit. This is a very widely-known flaw in the sysvinit design and basically every implementation that everyone else fixed. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
