The s6-linux-init-maker program

s6-linux-init-maker reads configuration options on the command line, and outputs a directory to place in the root filesystem. That directory contains a script suitable as an init program, as well as support file hierarchies to get a complete s6 infrastructure running when the system is booted on that script.

s6-linux-init-maker only writes scripts. At boot time, these scripts will call commands provided by other skarnet.org packages such as execline or s6. It is the responsibility of the administrator to make sure that all the dependencies are properly installed at boot time, and that the correct options have been given to s6-linux-init-maker so that the programs are found on the root filesystem of the machine - else the scripts will crash.

Interface and usage

     s6-linux-init-maker \
       [ -c basedir ] \
       [ -l tmpfsdir ] \
       [ -b execline_bindir ] \
       [ -u log_uid -g log_gid | -U ] \
       [ -G early_getty ] \
       [ -2 stage2 ] \
       [ -r ] \
       [ -Z ] stage2_finish \
       [ -3 stage3 ] \
       [ -p initial_path ] \
       [ -m initial_umask ] \
       [ -t timestamp_style ] \
       [ -d dev_style ] \
       [ -s env_store ] \
       [ -e initial_envvar ] ... \

dir should then be copied by the administrator to the place declared as basedir. Be careful: it contains fifos, files with precise uid/gid permissions, and files with non-standard access rights, so be sure to copy it verbatim. The s6-hiercopy tool can do it, as well as the GNU or busybox cp -a or mv commands.

The basedir/init script is then suitable as a "stage 1" init program, i.e. the first program run by the kernel. The administrator should make a symbolic link from /sbin/init to basedir/init; the machine will then be ready to boot

Boot sequence

When the kernel boots, it runs the basedir/init script, also known as stage 1. and this is what happens:

stage2 is the responsibility of the administrator - it will not be written automatically! It should contain all the necessary initialization sequence to bring up a proper system. When stage2 is executed, the machine state is as follows:

There is nothing else. In particular, no filesystem has been mounted yet, including /proc and /sys; and no one-time initialization has been performed. The point of stage 1 is only to make it possible to run stage2 with a logging infrastructure and a supervision infrastructure already available, and all the real machine and service initialization should happen in stage2.

Shutdown sequence

The examples/ subdirectory of the s6-linux-init package contains an example of /etc/rc.init, /etc/rc.tini and /etc/rc.shutdown scripts, suitable for stage2, stage2_finish and stage3 respectively. Those scripts can practically be used as is if the machine is managed by the s6-rc service manager.

s6-linux-init-maker options


The difficult parts of running s6-svscan as process 1 are:

The main benefit of s6-linux-init-maker is that it automates those parts. This means that it has been designed for real hardware where the above issues apply. If you are building an init system for a virtual machine, a container, or anything similar that does not have the /dev/console issue or the read-only rootfs issue, you will probably not reap much benefit from using s6-linux-init-maker: you could probably invoke s6-svscan directly as your process 1, or build a script by hand, which would result in a simpler init with less dependencies.