Why s6-linux-init ?

The s6 software stack

The s6 ecosystem is made of several parts, which are mainly the following:

Providing a complete init system

As explained in this presentation, an init system is made of four parts:

  1. /sbin/init: the first userspace program that is run by the kernel at boot time (not counting an initramfs).
  2. pid 1: the program that will run as process 1 for most of the lifetime of the machine. This is not necessarily the same executable as /sbin/init, because /sbin/init can exec into something else.
  3. a process supervisor.
  4. a service manager.

The s6 package obviously provides part 3. It also provides part 2, because s6-svscan is suitable as being pid 1 after some small setup is performed.

Part 4, service management, can be provided in a variety of ways. The s6-rc service manager is the natural complement to the s6 process supervisor, but it is not the only possibility. The anopa package also provides a service manager designed to work with s6. And, at the expense of tight integration with the supervisor, it is possible to run a "traditional" service manager, such as sysv-rc or OpenRC, with an s6-based init system. This flexibility is possible because service management is one layer above the mechanisms of init and process supervision.

Remains part 1. And that's where s6-linux-init enters the picture.


Part 1 of an init system, the /sbin/init program, has been purposefully omitted from the main s6 package, for a simple reason: s6 aims to be portable to any flavor of Unix, and it is impossible to implement /sbin/init in a portable way.

For instance, to do its job, s6-svscan needs a writable directory. Such a directory may not be available at boot time, before mounting filesystems, because the root filesystem may be read-only. So, at least one writable filesystem (typically a RAM-backed one) must be mounted before s6-svscan can be executed and be pid 1. And mounting a filesystem is a non-portable operation.


Moreover, the sequence of operations that a /sbin/init program needs to perform before executing into s6-svscan is a bit tricky. It can be scripted, but it's not easy, and since it's so early in the lifetime of the machine, there's no safety net at all (the supervision tree itself, and the early getty, are supposed to be the safety net, and they're not there yet). So it's better to automate these operations.


s6-linux-init aims to provide a fully functional /sbin/init program that executes into an s6 supervision tree with all the necessary support services already in place, as well as the corresponding shutdown commands. It also aims to be flexible enough to accommodate various needs and be compatible with any user-chosen service manager.

As usual, it is about mechanism, not policy.