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 bootdb ] [ -l live ] [ -p prefix ] [ -t timeout ] [ -b ] [ -d ] scandir
- bootdb (if the -d option hasn't been given), live and scandir must be absolute paths.
- s6-rc-init expects to find a compiled service database in bootdb. 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 bootdb as the current service database and sets the state as "all services down".
- It then copies verbatim all the service directories declared by bootdb 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 bootdb : declare bootdb as the current compiled service database for the upcoming live state. Default is /etc/s6-rc/compiled/current. Note that bootdb should always be a symlink pointing to the real compiled database: that is how databases can be live switched without modifying the boot process that invokes s6-rc-init.
- -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.
- -p prefix : when linking all the service directory into scandir, prepend the symbolic link names with prefix, i.e. a longrun named A will have its service directory accessible via scandir/prefixA. This allows several live directories to be used with a unique scandir without risking conflicts between longruns with the same name from different service databases. This option is only useful if you intend to have several sets of services independently managed by s6-rc, with different live directories, all using the same scandir to supervise their longruns. The default is no prefix at all, which is good when you only have one live directory.
- -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.
- -d : dereference bootdb. Fully resolve the bootdb path before declaring it as the current compiled service database for the upcoming live state. Using this flag in your init scripts' s6-rc-init invocation means that it's possible to boot on a compiled service database whose validity has not previously been guaranteed by a successful s6-rc-update invocation: you should know what you are doing.
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 bootdb 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.
- After s6-rc-init runs, bootdb has become the "live compiled database", and must not be tampered with or deleted. The only way to free it for deletion is to replace it with another database, via a call to s6-rc-update.