From b0fe68c13b04af8c098d53ea999bba6b7395163d Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Wed, 16 Sep 2020 12:04:55 +0000 Subject: Documentation fixes, by flexibeast --- doc/why.html | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) (limited to 'doc/why.html') diff --git a/doc/why.html b/doc/why.html index 3ce1612..83647cb 100644 --- a/doc/why.html +++ b/doc/why.html @@ -26,14 +26,14 @@
  • Good (?) old System V init, which can be made to supervise services if you perform /etc/inittab voodoo. BSD init can also be used the same way with the /etc/ttys file, but for some reason, nobody among BSD developers is using /etc/ttys to this purpose, so I won't consider BSD init here.
    • -
  • daemontools, the pioneer
    • -
  • daemontools-encore, Bruce Guenter's upgrade to daemontools
    • +
  • daemontools, the pioneer
    • +
  • daemontools-encore, Bruce Guenter's upgrade to daemontools
  • runit, Gerrit Pape's suite, well-integrated with Debian
  • perp, Wayne Marshall's take on supervision
  • Integrated init systems providing a lot of features, process supervision being one of them. -For instance, Upstart, MacOS X's -launchd, -and Fedora's systemd.
    • +For instance, Upstart, MacOS X's +launchd, +and Fedora's systemd.

    @@ -67,7 +67,7 @@ never wakes up unless it receives a command via s6-svscanctl.

  • System V init is process 1, so no problem here.
  • Integrated init systems, by definition, provide a process 1.
  • daemontools was not designed to take over init, although -it can be made to work with +it can be made to work with enough hacking skills. Same thing with daemontools-encore.
  • runit provides an init functionality, but the mechanism is separate from the supervision itself; the runit process, not the @@ -102,7 +102,9 @@ process 1 against libdbus. This is insane. Process 1 should be absolutely stable, it should be guaranteed to never crash, so the whole of its source code should be under control. At Upstart's level of complexity, those goals are outright impossible to achieve, -so this approach is flawed by design.
    • +so this approach is flawed by design. It is a shame, because the concepts +and ideas behind Upstart are good and sound; it's the +implementation choices that are its downfall.
  • launchd suffers from the same kind of problems. Example: Services running under launchd must be configured using @@ -163,10 +165,10 @@ and instantly respond to commands they may receive. s6-supervise has even been implemented as a full deterministic finite automaton, to ensure it always does the right thing under any circumstance. Other supervision suites do not achieve that for now.
    • -
  • daemontools' svscan +
  • daemontools' svscan maintains an open pipe between a daemon and its logger, so even if the daemon, the logger, and both -supervise processes +supervise processes die, the pipe is still the same so no logs are lost, ever, unless svscan itself dies.
  • runit has only one supervisor, runsv, -- cgit v1.2.3