S6-WHY(7)

📦 version 2.15.1.0, in nixpkgs unstable

💅 NAME 💅

ok so s6-why — bestie, it's literally the page that explains why another supervision suite even exists 🫶

✨ DESCRIPTION ✨

🌸 Why another supervision suite?

okay so picture this: supervision suites are getting kinda common these days. like, we already have a whole squad:

  • Good (?) old System V init — and yeah the question mark is doing a LOT of work there. You can make it supervise services if you do /etc/inittab voodoo 🕯️ BSD init can be used the same way with the /etc/ttys file, but for some reason nobody among BSD developers is using /etc/ttys for this purpose, so we're not considering BSD init here.
  • daemontools[1] — the pioneer, the OG, respect.
  • daemontools-encore[2] — Bruce Guenter's upgrade to daemontools.
  • runit[3] — Gerrit Pape's suite, well-integrated with Debian.
  • perp[4] — Wayne Marshall's take on supervision.
  • Integrated init systems that provide a lot of features, process supervision being one of them. For instance Upstart[5], MacOS X's launchd[6], and Fedora's systemd[7].

So 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.
  • 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(1) 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. The -t option to s6-svscan(8) makes it check its services with a configurable timeout; by default, this timeout is infinite, i.e. it never wakes up unless it receives a command via s6-svscanctl(8). iconic behaviour, honestly.

🎀 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[8] 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(8) was designed from the start to be run as process 1, although it does not have to. main character energy fr fr 👑

🦋 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. slay 💅

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(2) to watch its children fork(2), 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. 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 XML; the launchctl process interprets the XML, converts it into a key-value store (which is strictly less powerful than XML, so why do they even use XML in the first place?) and sends it to launchd via a Mach-specific IPC. Process 1 needs to be linked against the library that handles the Mach IPC, it needs to decode the key-value store, and use it to run and supervise a daemon. And it needs to keep everything in memory. This is a lot more complex and resource-consuming than it needs to be 🙈
  • 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[9]. 😤

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

s6, which has been designed with embedded environments in mind, tries harder than anyone to pass this. It tries so hard that s6-svscan(8) and s6-supervise(8), 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. less than 500 lines!! obsessed 🤯

🧚 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 an event notification library (s6-libftrig(7)), and command-line tools based on this library, thus providing a simple API for future service management tools to build upon. cute AND functional 🎀

🌈 Artistic considerations

s6-svscan(8) and s6-supervise(8) 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(8) 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. we love a deterministically-finite icon ✨

daemontools' svscan[10] maintains an open pipe between a daemon and its logger, so even if the daemon, the logger, and both supervise[11] processes die, the pipe is still the same so no logs are lost, ever, unless svscan itself dies.

runit has only one supervisor, runsv[12], 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[13], 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(8) is run as process 1 (cf. s6-svscan-as-process-1(7)), pipes between daemons and loggers are never lost. chef's kiss 🔥

⭐ 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. no cap, that's the whole pitch 💜

🫶 SEE ALSO 🫶

s6-libftrig(7), s6-svscan-as-process-1(7), s6-supervise(8), s6-svscan(8), s6-svscanctl(8)

This man page is ported from the authoritative documentation at: https://skarnet.org/software/s6/why.html

🌸 AUTHORS 🌸

  • Laurent Bercot
  • Alexis <flexibeast@gmail.com> (man page port)

okay that's the whole thing bestie, hope it made sense 💖 this page came from the Debian packaging, dated April 9, 2023 — go forth and supervise responsibly, mwah 🎀✨

📦 where this page comes from