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-init [ -c compiled ] [ -l live ] [ -p prefix ] [ -t timeout ] [ -b ] scandir
- compiled (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 compiled. It expects to be able to create a directory
named live. It also expects that an instance of
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
which will pick up the new service directories and start
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.
- -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
- -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
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 compiled. Fully resolve
the compiled path before declaring it as the current
compiled service database for the upcoming live state. This allows
compiled to be a symlink that can be updated later without
impacting the current 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.
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-rc-init should be the first command in the
stage2 (by default /etc/rc.init) script.
- 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.
- After s6-rc-init runs, compiled 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.