From 90b12bd71bb9fc79a4640b9112c13ef529d0196a Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Fri, 5 Dec 2014 22:26:11 +0000 Subject: Initial commit --- doc/why.html | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 203 insertions(+) create mode 100644 doc/why.html (limited to 'doc/why.html') diff --git a/doc/why.html b/doc/why.html new file mode 100644 index 0000000..1901259 --- /dev/null +++ b/doc/why.html @@ -0,0 +1,203 @@ + + + + + s6: why another supervision suite + + + + + + +

+s6
+Software
+skarnet.org +

+ +

Why another supervision suite ?

+ +

+ Supervision suites are becoming quite common. Today, we already have: +

+ +

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
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.

+ +

+ Why is s6 needed ? What does it do differently ? Here are the criteria I used. +

+ + +

Supervision suites should not wake up unless notified.

+ +

System V init fails the test: it wakes up every 5 seconds, for the reason that +/dev/initctl might have changed. +m(
daemontools fails the test: it wakes up every 5 seconds to check for new services.
daemontools-encore does the same.
the current version of runit fails the test: it wakes up every 14 seconds. But this is a workaround for a bug in some Linux kernels; +there is no design flaw in runit that prevents it from passing the test.
perp works.
Upstart works. I have no idea what other integrated init systems do: it's much too difficult to strace them +to see exactly where they're spending their time, and when it is possible, the trace output is so big that it's +hard to extract any valuable information from it.
s6 works. By default, s6-svscan wakes up every 5 seconds, to emulate +svscan behaviour; but it +can be told not to do so. (s6-svscan -t0)

+ + +

Supervision suites should provide a program that can run as process 1.

+ +

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 +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 +runsvdir process, runs as process 1. This lengthens the supervision +chain.
perp was not designed to run as process 1. It probably could be made to work too +without too much trouble.
s6-svscan was designed from the start to be run as process 1, although it +does not have to.

+ + +

Supervision suites should be bug-free, lightweight and easy to understand.

+ +

daemontools, daemontools-encore, runit and perp all qualify. All of this is excellent quality +code, unsurprisingly.
System V init is understandable, and reasonably lightweight; but it is still +too big for what it does - poorly. The /etc/inittab file needs to be parsed; +that parser has to be in process 1. There is support in process 1 for the whole +"runlevel" concept, which is a primitive form of service management. The same +executable handles all 3 stages of the machine's lifetime and does not separate +them properly. All in all, System V init does its job, but is showing its age +and nowadays we know much better designs.
This is where integrated init systems fail, hard. By wanting to organize +the way a the machine is operated - so, machine state management - in the +same package as the init and process supervision system, they add +incredible complexity where it does not belong. +
- Upstart uses ptrace to watch its children fork(), and links +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.
- launchd suffers from the same kind of problem. Regardless of how +things are actually implemented inside (which I have no idea about), services +running under launchd must be configured +using +XML. That means there is an XML parser in process 1. +What +could possibly go wrong ?
- systemd is much, much worse than the other ones, and a real danger +for the future of GNU/Linux. I have a special page +dedicated to it.
+ What those systems fail to recognize is that process supervision, rooted in +process 1, is a good thing, and machine management is also a good thing, but +those are two different functions, and a good init system +needs, and should, only provide process supervision, in +order to keep such a crucial piece of code as easy to maintain as possible. +Machine management can be added on top of a process supervision +suite, in a different package, and it has nothing to do with process 1.
s6, which has been designed with embedded environments in mind, tries +harder than anyone to pass this. It tries so hard that s6-svscan +and s6-supervise, the two long-running programs that make the +supervision chain, do not even allocate heap memory, and their main +program source files are less than 500 lines long.

+ + +

Supervision suites should provide a basis for high-level service management.

+ +

Neither System V init, daemontools, runit or perp +provides any hooks to wait for a service to go up or down. runit provides a +waiting mechanism, but it's based on polling, and the ./check script +has to be manually written for every service.
daemontools-encore qualifies: the notify script can be used for +inter-service communication. But it's just a hook: all the real notification +work has to be done by the notify script itself, no notification framework is +provided.
Integrated init systems provide high-level service management +themselves. Again, this is not good design: service management has nothing +to do with init or process supervision, and should be implemented on top +of it, not as a part of it.
s6 comes with libftrig, an event notification +library, and command-line tools based on this library, thus providing a simple +API for future service management tools to build upon.

+ + +

Artistic considerations

+ +

s6-svscan and s6-supervise are entirely asynchronous. +Even during trouble (full process table, for instance), they'll remain reactive +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 +maintains an open pipe between a daemon and its logger, so even if the daemon, +the logger, and both +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, +for both a daemon and its logger. The pipe is maintained by runsv. +If the runsv process dies, the pipe disappears and logs are lost. +So, runit does not offer as strong a guarantee as daemontools.
perp has only one process, perpd, +acting both as a "daemon and logger supervisor" (like runsv) and as a +"service directory scanner" (like runsvdir). It maintains the pipes +between the daemons and their respective loggers. If perpd dies, everything +is lost. Since perpd cannot be run as process 1, this is a possible SPOF for +a perp installation; however, perpd is well-written and has virtually no risk of +dying, especially compared to process 1 behemoths provided by integrated +init systems.
Besides, the runsv model, which has to handle both a daemon +and its logger, is more complex than the supervise model (which +only has to handle a daemon). Consequently, the runsvdir model is +simpler than the svscan model, but there is only one svscan +instance when there are several runsvs and supervises. +The perpd model is obviously the most complex; while very understandable, +perpd is unarguably harder to maintain than the other two.
So, to achieve maximum simplicity and code reuse, and minimal memory +footprint, s6's design is close to daemontools' one. +And when s6-svscan is run as process 1, +pipes between daemons and loggers are never lost.

+ + +

Conclusion

+ +

+ All in all, I believe that s6 offers the best overall implementation of a +supervision suite as it should be designed. At worst, it's just another +take on daemontools with a reliable +base library and a few nifty features. +

+ + + -- cgit v1.2.3