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 ] [ -t timeout ] [ -b ] scandir
- compiled, live and scandir must be
- 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
- -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.
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.