Why s6-linux-init ?

The s6 software stack

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

skalibs: a C system programming library that is used in all skarnet.org software.
execline: a small scripting language that is mainly used in various parts of the s6 ecosystem because:
- It is very quick to launch, and efficient with small scripts, so it is a good choice for s6 run scripts.
- It is much easier to programmatically generate execline scripts than shell scripts. execline allows programs such as s6-linux-init-maker to generate scripts quite easily, whereas using the shell syntax would require them to understand the full subleties of shell quoting.
s6, the main dish: a process supervision suite.
s6-rc: a service manager for s6.
and s6-linux-init: this package.

Providing a complete init system

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

/sbin/init: the first userspace program that is run by the kernel at boot time (not counting an initramfs).
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.
a process supervisor.
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.

Portability

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.

Complexity

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.

Conclusion

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.