On Wed 17/Oct/2018 23:06:24 +0200 Russ Allbery wrote: >> You say "more than adequate". I don't particularly see it as providing a >> solid system as you don't get restart on failure. Now I can see how >> people say that this is not a problem as daemons should not crash in the >> first place. Maybe I just value reliability of service more highly than >> being woken up at night being told that my service is unreliable.
> My point is that sysvinit is a non-default configuration and it's > reasonable to expect that it may be missing some features or robustness. > If you have the time and resources to put into equaling the robustness > that you would get under systemd, that's great, but sysvinit is much more > of a fire-and-forget system and is known to in general not have that > robustness property. sysvinit users who care will run something like > monit that watches health externally and takes appropriate action. Given the flavor of sysvinit —an easily customizable boot process— a missing init script may be better than a "wrong" one. An init script can be a no-brainer blueprint using Petter's init-d-script. A missing init script, which forces each user to write their own ones, would spare the hassle to check if there's any real improvement on each package upgrade. So here's a real advantage of systemd. Since users who prefer spoon-feeding use the latter, sysvinit can afford to let its users install a daemon and take the time to grasp how it works, e.g. reading the man page /before/ running it. Best Ale --
