S6-linux-init (package)

s6-linux-init is s6-based init system, with optional s6-rc support, on top of the Linux kernel]]. The package's documentation is provided in HTML format, and can be read on a text user interface using for example.

Environment variables

 * UID — For the 0.4.x.x series of s6-linux-init, the numeric user ID of the catch-all logger's effective user set by when invoked with the   option.
 * GID — For the 0.4.x.x series of s6-linux-init, the numeric group ID of the catch-all logger's effective group set by when invoked with the   option.

Files

 * — For s6-linux-init-1.0.0.0 and later, default stage2 init expected by.
 * — For s6-linux-init-1.0.0.0 and later, default shutdown file expected by.
 * — For s6-linux-init-1.0.3.0 and later, default final shutdown file expected by.
 * — For s6-linux-init-1.0.0.0 and later, default runlevel changer script expected by.
 * — For s6-linux-init-1.0.0.0 and later, default environment directory used by to set up the init system's supervision tree environment.
 * — For s6-linux-init-1.0.0.0 and later, default run image containing the init system's initial scan directory and catch-all logger's logging directory images.
 * — For the 0.4.x.x series of s6-linux-init, default environment directory used by the generated stage1 script to set up the init system's supervision tree environment.
 * — For the 0.4.x.x series of s6-linux-init, default run image containing the init system's initial scan directory and catch-all logger's logging directory images.
 * — For the 0.4.x.x series of s6-linux-init, default stage2 init expected by the generated stage1 script.
 * — For the 0.4.x.x series of s6-linux-init, default shutdown file expected by the generated diverted signal handlers.
 * — For s6-linux-init-1.0.0.0 and later, list of account names used by when invoked with an   option, to decide whether the machine shutdown request should be allowed to proceed or not.
 * — The init system's default scan directory.
 * — The init system's catch-all logger's default logging directory.

Usage
The package provides the program, which helps create several components of an s6-based init system, programs for shutting the machine down when the generated init system components are used, and support programs. Version 1.0.0.0 and later also provides tools for implementing runlevel-like functionality similar to that of sysvinit.

s6-linux-init-maker
The program must be run as root, so that it can create files and directories with appropriate owner, group and permissions, and must be invoked with a pathname as its argument. It creates a directory at the specified pathname, which must not exist beforehand, containing several init system components:


 * For the 0.4.x.x series of s6-linux-init, an execline script named, that is a stage1 init. For s6-linux-init-1.0.0.0 and later, the directory does not contain this script; instead, the package provides a program, also named , that is used as the stage1 init.
 * A subdirectory named, which contains:
 * An s6 scan directory image.
 * An empty directory named.
 * A subdirectory named, that might be empty.
 * For s6-linux-init-1.0.0.0 and later, a subdirectory named, containing shell scripts named , and . For s6-linux-init-1.0.3.0 and later, the  subdirectory also contains a shell script named.
 * For s6-linux-init-1.0.0.0 and later, a subdirectory named, containing sysvinit compatibility execline scripts.

To use these components to make an init system, they must be copied to appropriate filesystem locations. The script, which, for s6-linux-init-1.0.0.0 and later, is contained in the  subdirectory of the generated directory, must be copied to the place where the kernel is configured to find the program it'll run as process 1. For example, if the bootloader is configured to pass an  parameter to the kernel, then the  file generated by  must be copied to  and renamed as. The and  directories, and, for s6-linux-init-1.0.0.0 and later, the  directory, must be copied to the location the stage1 init expects them to be. For the sysvinit compatibility scripts, see here. Care must be taken to ensure that owner, group and permissions of files and subdirectories are preserved when copied to their destination place, e.g. by using GNU or BusyBox with the   option, or the  program from s6-portable-utils.

accepts a set of options that customize all these components. For the 0.4.x.x series of s6-linux-init, many of them use programs from packages s6-linux-utils and s6-portable-utils internally, so they are pulled in as runtime depencencies ( RDEPEND ). The only build-time dependency that needs itself is. sys-apps/s6-linux-init-1.0.0.0 and later only depend on and its dependencies.

The generated init system needs two files that must be supplied by the user to complete it: a stage2 init and a shutdown file, that must be executable. For the 0.4.x.x series of s6-linux-init, the shutdown file is used by the generated diverted signal handlers, and for s6-linux-init-1.0.0.0 and later, it is used by the shutdown daemon. For s6-linux-init-1.0.0.0 and later, the generated init system also needs a third file supplied by the user, the runlevel changer script, that is used by the program, and for s6-linux-init-1.0.3.0 and later, it also needs a fourth file supplied by the user, the final shutdown file, that is also used by the shutdown daemon.

For the full description of, please consult the HTML documentation in the package's subdirectory. A summary of each init system component and some of 's options that customize it follows.

The stage1 init
The init system's stage1 init runs as process 1 during the machine's boot sequence. The 0.4.x.x series of s6-linux-init creates it as an execline script named. For s6-linux-init-1.0.0.0 and later, it is a program supplied by the package, also named, and creates a compatibility script that just calls this program with suitable arguments.

In both cases, the stage1 init expects to access the contents of a certain base directory, and performs these actions:
 * It sets the PATH environment variable to a specified or default value.
 * It sets the working directory to /.
 * It sets the file mode creation mask to a specified or default value using a POSIX  call, via execline's  program in the execline script case.
 * It makes itself the leader of a new process group using a POSIX  call, via an  command in the execline script case.
 * It mounts a read-write tmpfs with options, using  from  in the execline script case.  also adds options   and  , and unmounts any other filesystem that might be mounted on the tmpfs mountpoint. Additionally:
 * If an  option is passed to, it assumes a tmpfs is already mounted, and remounts it with options  ,  ,   and  . This is useful when an initramfs is used that mounts the tmpfs itself and writes data to it that must be preserved.
 * If an  option is passed to, it assumes a tmpfs is already mounted, and does nothing. This is useful when an initramfs is used and it remains as the (read-write) rootfs of the machine.
 * Optionally, it mounts a devtmpfs on, again using in the execline script case.  adds options   and.
 * Optionally, it dumps the enviroment set up by the kernel to a specified enviroment store, using from  in the execline script case. The environment store is an environment directory suitable for.
 * It copies the subdirectory of the base directory to the tmpfs, preserving owner, group and permissions of files and subdirectories, using program  from s6-portable-utils in the execline script case.
 * It unsets all enviroment variables except PATH, using execline's program in the execline script case.
 * It adjusts the enviroment according to the subdirectory of the base directory, using  in the execline script case.
 * It spawns the stage2 init as a session leader using a POSIX  call, via  in the execline script case, with its standard input redirected to.
 * (s6-linux-init-1.0.3.0 and later) It uses a Linux  system call with an   command, to ask the kernel to send a   signal to process 1 when the ++ key combination is pressed (see here).
 * It redirects its standard output and error to the catch-all logger's FIFO, and replaces itself with, passing it the  (divert signals) and   (do not periodically scan the scan directory) options.

Aspects of the stage1 init that can be customized via options are:


 * The (absolute) pathname of the base directory: . Default:  for the 0.4.x.x series of s6-linux-init, and  for s6-linux-init-1.0.0.0 and later.
 * The value the PATH environment variable is initially set to: . This value affects all programs invoked by the execline script version of the stage1 init, the stage2 init, and, and will be the initial value of PATH for all the init system's supervision tree processes. Default:   for the 0.4.x.x series of s6-linux-init, and   for s6-linux-init-1.0.0.0 and later.
 * The initial value of the file mode creation mask for all the starting processes: . Default: 0022.
 * (0.4.x.x series of s6-linux-init only) The (absolute) pathname of the mountpoint for the read-write tmpfs: . Default:.
 * Whether a devtmps filesystem is mounted on or not:  . Default:  is left unmodified. Note that in order to make the stage1 init mount a devtmps, the syntax for the option is   (the number one) for the 0.4.x.x series of s6-linux-init, and   for s6-linux-init-1.0.0.0 and later.
 * The (absolute) pathname of a read-write directory for storing the kernel's environment variables (i.e. the environment store): . If no   option is given, the environment set up by the kernel is discarded before the stage1 init replaces itself with.
 * The initial environment of, and therefore, of all the init system's supervision tree processes: .  constructs subdirectory  of its created directory as an environment directory with all the variable settings specified by repeated use of this option. This directory must be copied to the base directory, where the stage1 init expects it to be. If no   options are given, 's environment will only have the PATH variable, and  will be empty.
 * (0.4.x.x series of s6-linux-init only) The (absolute) pathname of the user-provided stage2 init: . Default:.

For s6-linux-init-1.0.0.and later, the program expects the stage2 init to be named  and located in the  subdirectory of the base directory, and, on Gentoo, mounts the read-write tmpfs on. forwards the,  ,  ,   and   options, if specified, to  (via the sysvinit compatibility script), and accepts options   and  , which it also forwards to.

The stage2 init
The stage2 init must be provided by the user, runs as a child process of the stage1 init, and blocks until starts running as process 1. For the 0.4.x.x series of s6-linux-init, if is passed an   option ("redirect"), the stage1 script redirects the stage2 init's standard output and error to the catch-all logger's FIFO, i.e. all messages will be logged in its logging directory. Otherwise, the stage2 init's standard output and error are redirected to, i.e. the machine's console. The stage2 init is invoked with no arguments. An example stage2 init is provided, it is the execline script in the  directory of the package's  subdirectory.

For s6-linux-init-1.0.0.0 and later, the stage2 init's standard output and error are redirected to the catch-all logger's FIFO, and it is invoked with at least one argument: an initial runlevel. The initial runlevel is specified by passing a  option to, which it forwards to the  program. Every argument of is also forwarded to the stage2 init after the default runlevel. Arguments can be passed to by specifying them in the kernel's command line (e.g. using the bootloader's available mechanisms): every argument in the command line after a "--" (double hyphen) marker is passed to process 1, as is every argument before the marker, if present, that does not contain an equals sign ('=') or dot ('.'), and that is not recognized as a kernel parameter. For the meaning of runlevels in s6-linux-init, see here.

If no  option is specified,  scans its arguments and, if one of them is ,  ,  ,   or   then it is interpreted as the default runlevel, and passed to the stage2 init as its first argument (note that this means that this argument will be passed twice: as the first argument, and later again in the position is has in the kernel's command line), otherwise, the default runlevel passed to the stage2 init as its first argument is.

For s6-linux-init-1.0.0.0 and later, the program copies the stage2 init,, from a directory that can be specified with the   option, to the  subdirectory of its generated directory. If no  option is specified, directory  is used on Gentoo. The package installs an example stage2 init in, that is a shell script containing only comments.

The init system's scan directory
The scan directory image is the subdirectory of the stage1 init's base directory, and contains:


 * An s6 service directory for the init system's catch-all logger, named.
 * For s6-linux-init-1.0.0.0 and later, an s6 service directory for the runlevel changer service, named.
 * For s6-linux-init-1.0.0.0 and later, an s6 service directory for the shutdown service, named.
 * An optional s6 service directory for an early getty service, named.
 * The subdirectory with  and  files, as well as  diverted signal handlers. All of these files are execline scripts.

This scan directory image is copied to the tmpfs by the stage1 init, and becomes 's scan directory when it starts running as process 1. Therefore, the init system's scan directory's pathname, relative to the tmpfs' mountpoint, is, and, in most cases, its absolute pathname will be.

The generated and  files are execline scripts used by 's finish procedure and, for the 0.4.x.x series of s6-linux-init, the latter will be the init system's stage3 init. For s6-linux-init-1.0.0.0 and later, the file simply prints an "s6-svscan exited. Rebooting." message, and reboots the machine with an  command.

accepts a  option followed by a suitable invocation (program name and arguments) of some  implementation, for example,   for Gentoo. If it is invoked with this option, the early getty service directory contains a execline script with the specified  invocation, which means that a (single)  process will be spawned by  as soon as it starts running as process 1. This allows logging in to the machine from its console as early as possible. If no  option is specified, there will be no early getty service, and any  setup must be done by the user-provided stage2 init.

The catch-all logger
The catch-all logger generated by is an  process that logs to a logging directory named, and placed in the read-write tmpfs mounted by the stage1 init. Therefore, in most cases, the logging directory's absolute pathname will be. The standard output of the process is redirected to, and its standard error, to , i.e. the machine's console.

The file of its s6 service directory opens the logger's FIFO for reading, and then invokes  with the   option, so that it cannot be killed by the   signal, and with the   (blocking) option, which makes  stop reading from the FIFO while it has unflushed buffers. This avoids unbound memory use if there is a lot of output to write. For s6-linux-init-1.0.0.0 and later, the file alsso passes a   option to, which makes it signal readiness to its  parent process, using file descriptor 3 for the notification channel. The catch-all logger's FIFO is created by in its service directory with the name.

Aspects of the catch-all logger that can be customized via options are:


 * The process' effective user and group. Default:  runs as root.
 * For the 0.4.x.x series of s6-linux-init:,   and  . A numeric user ID and group ID can be specified with the   and   options, respectively, or be read from environment variables UID and GID , respectively, if the   option is used. This allows, for example the invocation of  as s6-envuidgid larry s6-linux-init-maker -U dir to make  run with effective user set to 'larry'.
 * For s6-linux-init-1.0.0.0 and later: . This option must be followed by an account database username.
 * How logged lines of text are timestamped:  . Default: timestamps in external TAI64N format are used, as generated by 's t directive.
 * (s6-linux-init-1.0.0.0 and later only) Whether the catch-all logger also prints logged lines to the machine's console:  (the number one). This is generally useful to debug a system at a glance, but if a failing program keeps sending error messages, it may interfere with comfortable usage of kernel virtual terminals. This can be avoided by not using  for any  process.

creates the subdirectory of its generated directory with an owner and group that are suitable for 's effective user and group, and the stage1 init copies it to the tmpfs.

The runlevel changer service
The runlevel changer service generated by is an  process that executes a user-provided runlevel changer script. The -  mechanism allows executing the script in a controlled, reproducible environment, i.e. the one set up for the init system's supervision tree processes. This is similar to the service that s6-rc uses for oneshots. The runlevel changer script runs with its standard input and output redirected to, and its standard error logged by the catch-all logger.

This service is used by the program.

The shutdown service and daemon
The shutdown service generated by is a supervised  process. It is used by the program.

s6-linux-init-1.0.0.0 and later provide the program, which is a shutdown daemon that takes care of performing the shutdown sequence. It runs as a long-lived process, and performs the following actions:


 * 1) It reads from a FIFO, which is created by  in its s6 service directory with the name, waiting for either machine shutdown requests, or shutdown cancellation requests. A shutdown request consists of an action, that can be halt, poweroff, reboot, or the special action S, a time value that specifies a delay until actual shutdown, and an optional grace period.
 * 2) If a shutdown request was received, it waits until the specified shutdown delay expires, and keeps reading from the FIFO in the meantime.
 * 3) If a shutdown cancellation request was received, it cancels any pending machine shutdown that has been previously requested.
 * 4) If the shutdown delay expires and the shutdown request has not been canceled, it starts the shutdown sequence by executing a shutdown file as a child process, and waiting for it to finish execution. The shutdown file must be provided by the user and, because  is part of the init system's supervision tree, it runs with the same environment that was set up for, its standard input redirected to , and its standard output and error logged by the catch-all logger.
 * 5) If the action specified in the shutdown request was S, it does nothing and starts reading again from the FIFO. This allows the implementation of a behaviour that is similar to sysvinit's single user mode. Otherwise:
 * 6) It redirects its standard output and error to, i.e. the machine's console.
 * 7) It creates an execline script named  in its s6 service directory.
 * 8) It stops all processes from the supervision tree except the catch-all logger, by renaming their service directories with a name that starts with a dot ('.'), and performing the equivalent of an  command. The renaming of the servicedirs prevents  from restarting their corresponding  process when it exits.
 * 9) It syncs all disks, flushing all the dirty system buffers, using a POSIX   call.
 * 10) It kills all remaining processes by sending them a   signal followed by a   signal, using POSIX   and   calls, and waits for the expiry of either the grace period specified in the shutdown request, or the default grace period.
 * 11) It kills all remaining processes by sending them a   signal using a   call. If  did not get killed by the signal, it exits.
 * 12) The shutdown service's corresponding  process restarts.
 * 13)  notes that there is a file named  in its service directory, and replaces itself with it using a POSIX   call.
 * 14) The execline script unmounts all mounted filesystem according to, and remounts the rootfs read-only, using auxiliary program.
 * 15) (s6-linux-init-1.0.3.0 and later) The execline script executes a final shutdown file as a child process, and waits for it to finish execution. This file must be provided by the user, and can be used to perform actions after all filesystems are unmounted. For example, to deactivate LVM logical volumes using a  command, or to wipe LUKS encrypted volumes' keys from kernel memory and remove their existing mappings using a  command. Just like, the final shutdown file runs with the environment set up for the init system's supervision tree processes, its standard input redirected to , and its standard output and error logged by the catch-all logger. The only filesystems that are still mounted during its execution are the rootfs (read-only), the tmpfs set up by  (read-write), and the devtmpfs, sysfs and proc filesystems, if mounted.
 * 16) The execline script invokes the  program with an   option to shut the machine down, passing an ,   or   option to it according to the action specified in the shutdown request (i.e. halt, poweroff or reboot).

expects the shutdown file and, for s6-linux-init-1.0.3.0 and later, the final shutdown file, to be named and, respectively, and expects both of them to be located in the  subdirectory of the stage1 init's base directory. It accepts a  option that specifies the absolute pathname of this directory, and a   option followed by a time value in milliseconds, specifying the duration of the default grace period. If no  option is specified, it assumes the base directory is, and if no   option is specified, the default grace period is 3 seconds. The grace period is capped to 5 minutes if the time value specified with a  option or in shutdown requests received via 's FIFO is greater than that.

For further information about, please consult the HTML documentation in the package's subdirectory. copies the shutdown file from a directory that can be specified with the  option, to the  subdirectory of its generated directory. If no  option is specified, directory  is used on Gentoo. The s6-linux-init package installs a shutdown file and a final shutdown file in, that are both shell scripts containing only comments.

Aspects of the shutdown service that can be customized via options are:


 * The default grace period: . Default: 3 seconds.

forwards the  option, if specified, to  (via the generated shutdown service's  file), and passes a   option to it using the value specified with the   option.

The diverted signal handlers
For the 0.4.x.x series of s6-linux-init, all diverted signal handlers are execline scripts that invoke a common shutdown file, wait for it to finish execution, and then invoke the  program to make  perform its finish procedure, which tears down the init system's supervision tree and initiates execution of the stage3 init. The shutdown file must be provided by the user and, because diverted signal handlers execute as child processes of, it runs with the same environment that was set up by the stage1 init for , its standard input redirected to , and its standard output and error logged by the catch-all logger. An example shutdown file is provided, it is the execline script in the  directory of the package's  subdirectory.

The behaviour of the different signals sent to process 1 when these handlers are used is:
 * : makes send a   signal to all its  children before performing its finish procedure, using an  command.
 * : makes send a   signal to all its  children before performing its finish procedure, using an  command.
 * : reboots the machine using an command. The operating system is usually configured to send a   to process 1 when key combination ++ is pressed.
 * : equivalent to.
 * : powers the machine off using an command.
 * : halts the machine using an command.

For s6-linux-init-1.0.0.0 and later, the generated diverted signal handlers are also execline scripts, and the behaviour of the different signals sent to process 1 when these handlers are used is:
 * : does nothing.
 * : does nothing.
 * : reboots the machine using an command.
 * : does nothing.
 * : powers the machine off using an command.
 * : halts the machine using an command.

Aspects of the signal handlers that can be customized via options are:


 * (0.4.x.x series of s6-linux-init only) The (absolute) pathname of the user-provided shutdown file: . Default:.

The stage3 init
For the 0.4.x.x series of s6-linux-init, the file in the  subdirectory of the init system's scan directory is a stage3 init. It is an execline script that runs as process 1 during the machine's shutdown sequence, and performs these actions:
 * 1) It sets the working directory to /.
 * 2) It redirects its standard output and error to, i.e. the machine's console.
 * 3) It uses an  command to make the catch-all logger exit.
 * 4) It syncs all disks, flushing all the dirty system buffers, using program  from.
 * 5) It kills all remaining processes by sending them a   signal followed by a   signal followed by a   signal, using program  from s6-portable-utils, and waits for the expiry of a specified or default grace period.
 * 6) It kills all remaining processes by sending them a   signal, again using.
 * 7) It unmounts all mounted filesystem according to  using program  from.
 * 8) Remounts the root filesystem read-only using program  from s6-linux-utils.
 * 9) Invokes the,  or  program with the   option to shut the machine down.

Aspects of the stage3 init that can be customized via options are:


 * (0.4.x.x series of s6-linux-init only) The duration of the grace period: . Default: 2 seconds.

Runlevels
s6-linux-init-1.0.0.0 and later allows the implementation of runlevel-like functionality similar to that of sysvinit. An s6-linux-init runlevel normally represents a service set, and entering a runlevel normally means to start all services in the corresponding set, and stopping all services not in it. Each runlevel has an alphanumerical identifier. The package uses two components to implement a service: the program, and the generated runlevel changer service,.

What happens when a runlevel is entered is defined by a runlevel changer script that must be provided by the user. expects the script to be named and located in the  subdirectory of the stage1 init's base directory. It is normally an execline or shell script that relies on some service manager to actually perform the necessary service transitions.

The program accepts a runlevel identifier as its argument, and uses an s6-sudo -e -T 3600000 command to connect to 's socket (i.e. the  process' listening socket), and pass it the runlevel identifier. The  option avoids passing variables from 's enviromnent to the the  script, and the   option prevents it from running for more than an hour. then executes with the runlevel identifier as its argument.

Integration with OpenRC can be achieved by having the runlevel changer script execute the program when invoked. In this case, s6-linux-init runlevels are OpenRC runlevels.

For compatibility with sysvinit, if is invoked with 0 or 6 as its argument, after passing it to  as the runlevel identifier and waiting for the  process to terminate, it uses an s6-linux-init-shutdown -h 0 or s6-linux-init-shutdown -p 0 command to initiate machine shutdown.

For further information about, please consult the HTML documentation in the package's subdirectory. copies the runlevel changer script from a directory that can be specified with the  option, to the  subdirectory of its generated directory. If no  option is specified, directory  is used on Gentoo. The s6-linux-init package installs a runlevel changer shell script in, containing only comments that illustrate integration with both OpenRC and s6-rc.

s6-rc support
All the necessary setup needed to make s6-rc part of the init system is done in the stage2 init and in the shutdown file invoked by either the diverted signal handlers or the shutdown daemon. Because both files are provided by the user, the s6-linux-init package does not have, or need, any specific support for s6-rc. Nevertheless, the stage2 init and shutdown file provided by the package illustrate an s6-rc setup.

Integration of with s6-rc can be achieved by having the runlevel changer script use its argument in a  command. In this case, s6-linux-init runlevels are s6-rc service bundle names.

Shutdown and reboot
The 0.4.x.x series of s6-linux-init provides the, and  programs, that can be used in combination with the init system components generated by  to shut the machine down. These programs halt it, power it off, and reboot it, respectively. They accept an  ("force") option, just like their sysvinit counterparts, to perform their respective action without going through the init system (using the Linux   system call). Otherwise, they just send a signal to process 1 that corresponds to the diverted signal handler generated by for the requested shutdown operation. For further information about these programs, please consult the HTML documentation in the package's subdirectory.

s6-linux-init-1.0.0.0 and later provides the and  programs for the same purpose. The former conforms to the LSB shutdown interface, modeled after sysvinit's , and the latter replaces , and. Therefore, accepts a time specification, an optional message to be shown to logged in users, and the   (halt after shutdown),   (reboot after shutdown),   (cancel shutdown),   (do not really shutdown; only warn),   (grace period between   and  ) and   (access control) options, with the same meaning as for sysvinit's. For compatibility with the LSB, it accepts  (ask the rc subsystem to skip checking filesystems with  after next boot) and   (ask the rc subsystem to make  check filesystems after next boot, even if they are marked clean) options, that it ignores. It also accepts  (halt),   and   (poeweroff) options, that combine with   according to the following table:

Unless it was invoked with the  option,  connects to the shutdown service's FIFO and sends a shutdown request, or shutdown cancellation request if the   option has been specified, to the shutdown daemon,. If no,  ,   or   option was specified, it sends a special 'S' shutdown request to , that only makes it execute the shutdown script, but not actually shut the machine down. This allows the implementation of a behaviour that is similar to sysvinit's single user mode.

If it was invoked with the  option,  performs access control using file  just like sysvinit's. POSIX,   and   calls are used to read user accounting database ( for GNU libc)  user process records (i.e.   objects with  ), and their   user field is matched against account usernames in. If the duration of the grace time specified with the  option is greater that 5 seconds, it is capped to that value.

For further information about, please consult the HTML documentation in the package's subdirectory.

The program must be invoked either with an   option, a   option, or an   option, to halt, poweroff, or reboot the machine, respectively. In either case, it first writes a shutdown record to the user accounting log file ( for GNU libc), using the libc's  function. The shutdown record is a runlevel record (i.e. a  object with  ) that has   set to "shutdown" (or "reboot" if  was invoked with the   option),   set to the empty string,   set to "",   set to 's process ID,   set to 's session ID (as returned by a POSIX   call),   set to the current time, and   set to the name returned by the POSIX   call (or the null string if the call fails). Then, unless it was invoked with a  (capital 'w') option, it prints a warning about the system going down immediatly to logged in users, and finally sends a shutdown request to, specifying that machine shutdown should be initiated immediately. That is, s6-linux-init-hpr -h is equivalent to s6-linux-init-shutdown -h now, s6-linux-init-hpr -p , to s6-linux-init-shutdown -p now , and s6-linux-init-hpr -r , to s6-linux-init-shutdown -r now.

Just like sysvinit's, and , if  is invoked with a   (small 'w') option, it only writes the shutdown record to the user accounting log file, without actually shutting the machine down, and if it is invoked with a   option, no shutdown record is written to the user accounting log file.

If is invoked with an   ("force") option, it syncs all disks, flushing all the dirty system buffers, using the POSIX   call, and directly performs the shutdown action requested by the ,   or   option, using the Linux   system call. No shutdown record is written to the user accounting log file, no warning is printed a to logged in users, and options,   and   are ignored.

For further information about, please consult the HTML documentation in the package's subdirectory.

sysvinit compatibility scripts
For s6-linux-init-1.0.0.0 and later, creates the following execline scripts in the  subdirectory of its generated directory:
 * , which calls the program with the   (base directory) and   (file mode creation mask) options, and, if they were specified to, the   (value of PATH ),   (mount a devtmpfs),   (environment store),   (initial runlevel),   (remount the tmpfs) and   (do not mount a tmpfs) options.
 * , which calls the program with the   option (halt) and all the supplied arguments.
 * , which calls the program with the   option (poweroff) and all the supplied arguments.
 * , which calls the program with the   option (reboot) and all the supplied arguments.
 * , which calls the program with all the supplied arguments.
 * , which calls the program with all the supplied arguments.

These compatibility scripts are provided as replacements of the sysvinit programs of the same name in pure s6-based setups, and are installed by the Gentoo ebuild in if the   USE flag is set. This, however, does not allow having and sys-apps/s6-linux-init simultaneously installed, and therefore, switching between init systems with a reboot. In fact, installing sys-apps/s6-linux-init with this USE flag set on a machine with sys-apps/sysvinit already installed results in a blocker. So, to be able to have both packages, sys-apps/s6-linux-init must be installed with the  USE flag unset, and the compatibility scripts, if wanted, must be (manually) installed with different names. For example:


 * , and  could be installed in  with the names,  and  since, for s6-linux-init-1.0.0.0 and later, those programs are replaced by  and no longer provided. Or alternatively, the administrator could use  directly, and not install the compatilibity scripts.
 * might be installed in as, for example,, and an   parameter could be passed to the kernel. Or alternatively, the  program could be specified in the   parameter, its agruments could be specified in the kernel command line after an '--' marker, and the compatilibity script could be left uninstalled.
 * The administrator could use and  directly, and not install the  and  compatilibity scripts.

Support programs
s6-linux-init-1.0.0.0 and later provides two support programs for init system components created by.

The program is used by the  and  files, and is an exact duplicate of  from. Its inclusion in s6-linux-init avoids creating a runtime dependency on that package.

The program is used by the  execline script created by the shutdown daemon,, and it unmounts all filesystems, processing  in reverse order, starting with the most recently mounted partition and ending with the rootfs. It behaves in a similar way to that of the program from  when the   option is specified. Its inclusion in s6-linux-init again avoids creating a runtime dependency on that package. For s6-linux-init-1.0.3.0 and later, skips the unmounting of the first instance of a devtmpfs, sysfs and proc filesystem it finds in, which would usually correspond to ,  and , respectively, so that they are available for the final shutdown file,.

Unmerge
If s6-linux-init's programs and components generated by are being used as the init system, an alternative one must be installed in parallel, and the machine rebooted to use it (possibly by reconfiguring the bootloader), before the package is removed, or otherwise the machine will become unbootable.

External resources

 * Adélie Linux, a distribution of Linux and musl that supports using s6-linux-init-1.0.0.0 and later + OpenRC as its init system, as an alternative to sysvinit + OpenRC (currently in beta stage).