An overview of s6

s6 is a collection of utilities revolving around process supervision and management, logging, and system initialization. This page is a high-level description of the different parts of s6.

Process supervision

At its core, s6 is a process supervision suite, like its ancestor daemontools and its close cousin runit.


The concept of process supervision comes from several observations:

A process supervision system organizes the process hierarchy in a radically different way.


s6 is a straightforward implementation of those concepts.

These four programs, s6-svscan, s6-supervise, s6-svscanctl and s6-svc, are the very core of s6. Technically, once you have them, you have a functional s6 installation, and the other utilities are just a bonus.

Practical usage

To use s6's supervision features, you need to perform the following steps:

Service-specific logging

s6-svscan can monitor a supervision tree, but it can also do one more thing. It can ensure that a daemon's log, i.e. what the daemon outputs to its stdout (or stderr if you redirect it), gets processed by another, supervised, long-lived process, called a logger; and it can make sure that the logs are never lost between the daemon and the logger - even if the daemon dies, even if the logger dies.

If your daemon is outputting messages, you have a decision to make about where to send them.

s6 provides you with a long-lived process to use as a logger: s6-log. It will store your logs in one (or more) specific directory of your choice, and rotate them automatically.

Helpers for run scripts

Creating a working service directory, and especially a good run script, is the most important part of the work when adapting a daemon to a supervision framework.

If you can find your daemon's invocation script on a non-supervision system, for instance a System V-style init script, you can see the exact options that the daemon is being run with: environment variables, uid and gid, open descriptors, etc. This is what you need to replicate in your run script.

(Do not replicate the auto-backgrounding, or things like start-stop-daemon invocation: start-stop-daemon and its friends are hideous and kludgy attempts to work around the lack of proper supervision mechanisms. Now that you have s6, you should remove them from your system, throw them into a bonfire, and dance and laugh while they burn. Generally speaking, as a system administrator you want daemons that have been designed following the principles described here, or at least you want to use the command-line options that make them behave in such a way.)

The vast majority of the tools provided by s6 are meant to be used in run scripts: they help you control the process state and environment in your script before it executes into your daemon. Or, sometimes, they are daemons themselves, designed to be supervised.

s6, like other skarnet.org software, makes heavy use of chain loading, also known as "Bernstein chaining": a lot of s6 tools will perform some action that changes the process state, then execute into the rest of their command line. This allows the user to change the process state in a very flexible way, by combining the right components in the right order. Very often, a run script can be reduced to a single command line - likely a long one, but still a single one. (That is the main reason why using the execline language to write run scripts is recommended: execline makes it natural to handle long command lines made of massive amounts of chain loading. This is by no means mandatory, though: a run script can be any executable file you want, provided that running it eventually results in a long-lived process with the same PID.)

Some examples of s6 programs meant to be used in run scripts:

Readiness notification and dependency management

Now that you have a supervision tree, and long-lived processes running supervised, you may want to introduce dependencies between them: do not perform an action (e.g. start (with s6-svc -u) the Web server connecting to a database) before a given daemon is up and running (e.g. the database server). s6 provides tools to do that:

s6 does not provide a complete dependency management framework, i.e. a program to automatically start (or stop) a set of services in a specific order - that order being automatically computed from a graph of dependencies between services. That functionality belongs to a service manager, and is implemented for instance in the s6-rc package.

Fine-grained control over services

s6 provides you with a few more tools to control and monitor your services. For instance:

These tools make s6 the most powerful and flexible of the existing process supervision suites.

Additional utilities

The other programs in the s6 package are various utilities that may be useful in designing servers, and more generally multi-process software. They can be used with or without a supervision environment, although it is of course recommended to have one; but they are not part of the core s6 functionality, and you may safely ignore them for now if you are just getting into the supervision world.

Generic inter-process notification

The s6-ftrig* family of programs allows notifications between unrelated processes: a set of processes can subscribe to a certain channel - identified by a directory in the filesystem - and ask to be notified of certain events on that channel; another set of processes can send events to the channel.

The underlying mechanism is the same as the one used by the supervision tree for readiness notification, but the s6-ftrig* tools provide a more generic access to that mechanism.

Helpers for designing local services

Local services, i.e. daemons listening to a Unix domain socket, are a powerful and flexible mechanism, especially with modern Unix systems that allow client authentication. s6 includes tools to take advantage of that mechanism.

Keeping file descriptors open

Sometimes you want to keep a file descriptor open, even if the program normally using it dies - so the program can restart and use the same file descriptor without losing any data. To do that, you need to hold the descriptor in another process, i.e. that process should have it open but do nothing with it.

s6-svscan, for instance, holds the pipe existing between a supervised daemon and its logger, so even if the daemon or the logger dies while there are logs in the pipe, the pipe remains open and the logs are not lost.

s6 provides a mechanism to store and retrieve open file descriptors in a totally generic way: the s6-fdholder* family of programs.

Note that "socket activation", one of the main advertised benefits of the systemd init system, sounds similar to fd-holding. The reality is that socket activation is a mixture of several different mechanisms, one of which is fd-holding; s6 allows you to implement the healthy parts of socket activation.

Other miscellaneous utilities

This page does not list or classify every s6 tool. Please explore the "Reference" section of the main s6 page for details on a specific program.