The s6-rc-init program

s6-rc-init is an initialization tool for the s6-rc system. It must be run as root, at boot time, prior to any invocation of the s6-rc binary.

Interface

     s6-rc-init [ -c compiled ] [ -l live ] [ -t timeout ] [ -b ] scandir

compiled, live and scandir must be absolute paths.
s6-rc-init expects to find a compiled service database in compiled. It expects to be able to create a directory named live. It also expects that an instance of s6-svscan is running on scandir.
s6-rc-init initializes the live state in live. It declares compiled as the current service database and sets the state as "all services down".
It then copies verbatim all the service directories declared by compiled into a subdirectory of live, adds ./down files to the live copies and links those live copies into scandir. It then triggers s6-svscan, which will pick up the new service directories and start s6-supervise processes on them - but the service themselves will not be started right away, because of the ./down files.
s6-rc-init waits for all s6-supervise processes to be operational, then exits 0.

Options

-t timeout : if all s6-supervise processes are not up and running after timeout milliseconds, s6-rc-init will complain and exit 111. This is a safety feature so s6-rc-init doesn't hang indefinitely on a nonworking installation; normally this initialization should not take more than a few milliseconds.
-c compiled : declare compiled as the current compiled service database for the upcoming live state. Default is /etc/s6-rc/compiled.
-l live : Store the live state into the live directory, which should not exist prior to running s6-rc-init, but should be under a writable filesystem - likely a RAM filesystem. Default is /run/s6-rc. The default can be changed at compile time by giving the --livedir=live option to ./configure.
-b : blocking lock. If the database is currently being used by another program, s6-rc-init will wait until that other program has released its lock on the database, then proceed. By default, s6-rc-init fails with an error message if the database is currently in use.

Typical usage

Administrators should invoke s6-rc-init once, in their early boot scripts, after s6-svscan is functional and ready to supervise longrun services (and after its catch-all logger, if any, has started), but before any other initialization. (The rest of the initialization can be written as a set of s6-rc services, and performed by just one invocation of the s6-rc change command.)

For instance, when using an init created by s6-linux-init, s6-rc-init should be the first command in the stage2 (by default /etc/rc.init) script.

Notes

The directory created by s6-rc-init will actually be called live:initial, and live will be a symbolic link to that directory. Users should ignore this, and always refer to the live directory as live in their future s6-rc or s6-rc-update invocations. The reason for this behaviour is that s6-rc-update creates another, similarly named, directory (live:suffix) and updates the live state by atomically changing the target of the live symlink - so live will not change names, whereas the real directory may.)
Similarly, it is recommended that administrators store their compiled service databases into some versioned directory, and that compiled be a symbolic link to the database currently in use. This will make it easier to create new compiled databases and switch them with s6-rc-update without having to change the s6-rc-init invocation in boot scripts.