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.
At its core, s6 is a process supervision suite, like its ancestor
daemontools and its
The concept of process supervision comes from several observations:
- Unix systems, even minimalistic ones, need to run
long-lived processes, aka daemons. Sometimes, they
need to run a lot of them.
- Daemons can die unexpectedly. Maybe they are missing a vital
resource and cannot handle a certain failure; maybe they tripped on a bug;
maybe a misconfigured administration program killed them; maybe the
kernel killed them.
- Automatically restarting daemons when they die is generally a good
thing. In any case, sysadmin intervention is necessary, but at least the
daemon is providing service, or trying to, until the sysadmin can log in
and investigate the underlying problem.
- Ad-hoc shell scripts that restart daemons suck, for
several reasons that would each justify their own page. The difficulty of
keeping track of the PID, explained below, is one of those reasons.
- It is sometimes necessary to send signals to a daemon. To kill it,
of course, but also to make it read its config file again, for instance;
signalling a daemon is a natural and very common way of sending it
- Generally, to send a signal to a daemon, you need to know its PID.
Without a supervision suite, knowing the proper PID is hard. Most
non-supervision systems use a hack known as .pid files, i.e.
the script that starts the daemon stores its PID into a file, and other
scripts read that file. This is a bad mechanism for several reasons, and
the case against .pid files would also justify its own page; the most
important drawback of .pid files is that they create race conditions
and management scripts may kill the wrong process.
- Non-supervision systems provide scripts to start and stop daemons,
but those scripts may fail at boot time even though they work when run
and vice versa. If a sysadmin logs in and runs the script to restart a
daemon that has died, the result might not be the same as if the whole
system had been rebooted, and the daemon may exhibit strange behaviours!
This is because the boot-time environment and the restart-time environment
are not the same when the script is run; and a non-supervision system
just cannot ensure reproducibility of the environment. This is a core
problem of non-supervision systems: countless bugs have been falsely
reported because of simple environment differences or configuration errors,
countless man-hours have been wasted to try and understand what was
A process supervision system organizes the process hierarchy in a
radically different way.
- A process supervision system starts an independent hierarchy of
processes at boot time, called a supervision tree. This
supervision tree never dies: when one of its components dies, it is
restarted automatically. To ensure availability of the supervision
tree at all times, it should be rooted in process 1, which cannot die.
- A daemon is never started, either manually or in a script, as a
scion of the script that starts it.
Instead, to start a daemon, you configure a
specific directory which contains all the information about your daemon;
then you send a command to the supervision tree. The supervision tree
will start the daemon as a leaf. In a process supervision
system, daemons are always spawned by the supervision tree, and
never by an admin's shell.
- The parent of your daemon is a supervisor. Since your
daemon is its direct child, the supervisor always knows the
correct PID of your daemon.
- The supervisor watches your daemon and can restart it when it
- The supervision tree always has the same environment, so starting
conditions are reproducible. Your daemon will always be started with the
same environment, whether it is at boot time via init scripts or for the
100th automatic - or manual - restart.
- To send signals to your daemon, you send a command to its
supervisor, which will then send a signal to the daemon on your behalf.
Your daemon is identified by the directory containing its information,
which is stable, instead of by its PID, which is not stable; the supervisor
maintains the correct association without a race condition or the other
problems of .pid files.
s6 is a straightforward implementation of those concepts.
- The s6-svscan and
s6-supervise programs are the components
of the supervision tree. They are long-lived programs.
- s6-supervise is a daemon's
supervisor, its direct parent. For every long-lived process on a
system, there is a corresponding s6-supervise
process watching it. This is okay, because every instance of
s6-supervise uses very few resources.
- s6-svscan is, in a manner of speaking,
a supervisor for the supervisors. It watches and maintains a collection of
s6-supervise processes: it is the branch
of the supervision tree that all supervisors are stemming from. It can be
by your regular init process, or it can
process 1 itself. Running s6-svscan as process 1 currently requires
some manual effort from the user, because of the inherent non-portability
of init processes; future versions of s6 will automate that effort and
provide users with ready-to-run "init" commands.
- The configuration of a daemon to be supervised by
s6-supervise is done via a
- The place to gather all service directories to be watched by a
s6-svscan instance is called a
- The command that controls a single supervisor, and allows you to
send signals to a daemon, is
s6-svc. It is a short-lived program.
- The command that controls a set of supervisors, and allows you to
start and stop supervision trees, is
s6-svscanctl. It is a short-lived
These four programs,
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.
To use s6's supervision features, you need to perform the following steps:
- For every daemon you potentially want supervised, write a
service directory. Make sure that
your daemon does not background itself when started in the
./run script! Auto-backgrounding is a historical hack
that was implemented when supervision suites did not exist; since
you're using a supervision suite, auto-backgrounding is unnecessary
and in this case detrimental.
- Write a single scan directory for
the set of daemons you want to actually run. This set can be modified
at run time.
- At some point in your initialization scripts, run
s6-svscan on the scan directory. This will
start the supervision tree, including your set of daemons. The exact
way of running s6-svscan depends on your system: it is not quite the same
when you want to run it as process 1 on a real machine, or under another
init on a real machine, or as process 1 in a
Docker container, or in another
- Alternatively, you can start s6-svscan
on an empty scan directory, then populate it step by step and send an
update command to s6-svscan via
s6-svscanctl whenever the supervision
tree should pick up the differences and start the services you added.
- That's it, your services are running. To control them manually,
you can use the s6-svc command.
- At the end of the system's lifetime, you can use
s6-svscanctl to bring down the supervision
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
If your daemon is outputting messages, you have a decision to make
about where to send them.
- You can do as non-supervision systems do, and send the messages
to syslog. It's entirely possible with a supervision system too.
However, like auto-backgrounding, syslog is a historical mechanism that
predates supervision suites, and is technically inferior; it is
recommended that you do not use it whenever you can avoid it.
- You can send them to the daemon's stdout/stderr and do nothing special
about it. The logs will then be sent to s6-svscan's stdout/stderr;
what mechanism will read them depends on how you started s6-svscan.
- You can use s6-svscan's service-specific logging mechanism and
dedicate a logger process to your daemon's messages.
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
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.)
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
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
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:
- The s6-log program is a long-lived
process. It is meant to be executed into by a ./log/run
script: it will be supervised, and will process what it reads on
its stdin (i.e. the output of the ./run daemon).
- The s6-envdir program is a
short-lived process that will update its current environment according
to what it reads in a given directory, then execute into the rest of its
command line. It is meant to be used in a run script to adjust the
environment with which the final daemon will be executed into.
- Similarly, the s6-softlimit program
adjusts its resource limits, then executes into the rest of its command
line: it is meant to set the resources the final daemon will have
- The s6-applyuidgid program,
part of the s6-*uidgid family, drops root privileges before
executing into the rest of its command line: it is meant to be used
in run scripts that need root privileges when starting but do not
need it for the execution of the long-lived process.
- s6-ipcserverd is a daemon that
listens to a Unix socket and spawns a program for every connection.
It is meant to be supervised, so it should be used in a run script,
and it's also meant to be a flexible super-server that you can use
for different applications: so it is a building block that may appear in
several of your run scripts defining
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:
- The s6-svwait,
s6-svlisten programs will wait until a set of
daemons is up, ready, down (as soon as the ./run process dies) or
really down (when the ./finish process has also died).
- Unfortunately, a daemon being up does not mean that it is
this page goes into the details. s6
supports a simple mechanism: when a daemon wants to signal that it is
ready, it simply writes a newline to a file descriptor of its
choice, and s6-supervise will pick that
notification up and broadcast the information to processes waiting for
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
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.
- The s6-ipc* family of programs is about designing clients
or servers that communicate over Unix domain sockets.
- The s6-*access* and s6-connlimit
family of programs is about client access control.
- The s6-sudo* family of programs is about using a local
service in order to give selected
clients the ability to run a command line with the privileges of the
server, without using suid programs.
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.
- The s6-fdholder-daemon program
is a daemon (or, rather, executes into the
s6-fdholderd daemon), meant to be
supervised, that will hold file descriptors on its clients' behalf.
- Other programs in the family, such as
s6-fdholder-store, are client
programs that interact with this daemon to store and retrieve file
Note that "socket activation", one of the main advertised benefits of the
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.