Sysvinit

sysvinit is Article description::a collection of System V-style init programs originally written by Miquel van Smoorenburg. They include, which is run by the kernel as process 1, and is the parent of all other processes. On Gentoo, it is a component of one of its two supported init systems, with the OpenRC service manager on top of it to implement the rc subsystem.

Environment variables

 * CONSOLE - Pathname will use as that of machine console's device node.

Files

 * - 's configuration file.
 * - If present, used by to spawn processes specified in its configuration file.
 * - 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.
 * (formerly ) - Used by for its power failure and restoration routines.

Usage
The sysvinit package provides:


 * and its control program,.
 * The, , , and programs, that shut the machine down if  is running as process 1.
 * The daemon.
 * The, , and utilities.

The upstream package provides additional programs, but Gentoo does not install them, in favor of their counterparts from other packages.

init and telinit
is executed by the kernel as process 1. No special administrator intervention is required for this; during the machine's boot sequence, the kernel automatically looks for a program named 'init' in directories, and , in that order, unless the   parameter has been specified in its command line (e.g. using the bootloader's available mechanisms).

runs for the entire machine's uptime and performs these tasks:


 * Spawns a set of child processes, as specified in its configuration file, . A subset of these processes carry out the machine's initialization tasks, needed to bring it to its stable, normal 'up and running' state, usually by relying on the rc subsystem's mechanisms.
 * Reaps zombie child processes using the POSIX  call. Zombie processes are those that have exited or have been killed by a signal, which causes the kernel to send a   signal to their parent. The children of  include orphaned processes that were reparented to it by the kernel.
 * Supervises child processes that have a corresponding entry with a   or   action (see here).
 * Reacts to received signals.
 * Reacts to commands received via its control FIFO, . creates this FIFO if it doesn't already exist, with permissions 0600 (i.e. the  command would show  ). For sysvinit version 2.88, the control FIFO is.

prints its messages on the machine's console, and also sends messages to a syslog server using the libc's implementation (i.e. that of the POSIX,   and   calls). Each time needs to use the console, it opens the corresponding device node, and closes it after use. If the CONSOLE environment variable is set, uses its value as the pathname of the console's device node, instead of. 's syslog messages specify facility  and severity.

specifies processes to be started by both during the boot sequence, and during normal operation. Processes started during normal operation are assigned to groups named runlevels. sysvinit runlevels are identified by a number in the range from 0 to 9. Runlevels 0, 1 and 6 have assigned meaning and are given special treatment by. Runlevels 7 to 9, although existent, have inconsistent treatment in 's code compared to the others, and are usually avoided. Additionally, sysvinit supports ondemand procedures, and special modes of operation called emergency mode and single user mode.

OpenRC also uses the term 'runlevel' to refer to service sets, but these are identified by names instead, like sysinit, default, shutdown, etc. OpenRC's named runlevels are independent of sysvinit numeric runlevels, but correlated on Gentoo.

is 's control program. It can be invoked in two ways: with a single-character argument, and optionally a  option (e.g. telinit 2, telinit -t 7 a , telinit q , etc.), or with a sequence of   options followed by environment variable settings (e.g. telinit -e VAR1 -e VAR2=value ).

For the full description of and, please consult their respective man page. A summary of their functionality follows.

The inittab file
is a text file that must contain a sequence of single-line entries. Each entry is composed by four fields separated by colons (':'), optionally preceded by a sequence of whitespace characters (space and TAB):


 * The first one is the identifier field, a sequence of characters that uniquely identifies the entry. This identifier gets written to user accounting database login records (see ), so its maximum length is the size of the  field of the libc's   type (4 characters in the case of GNU libc). Identifier '' is reserved.
 * The second one is the runlevels field, a sequence of characters that generally represents a set of runlevels.
 * The third one is the action field, it specifies when the program named in the next field must be executed, and how it must be executed.
 * The fourth and last one is the process field, it specifies a program name or its pathname, and the program's arguments.

If the first non-whitespace character in a line is '#', the line is treated as a comment and ignored. The possible values of the action field are:


 * ,  and  . Entries with these action fields associate programs with runlevels, and specify how the program specified in the process field must be executed. An empty runlevels field in these kinds of entries is the same as one containing.
 * ,,   and  . Entries with these action fields are used during the machine's boot sequence. The process field of   entries is ignored, and so is the runlevels field of  ,   and  entries.
 * . Entries with these action types can be used for ondemand procedures.
 * ,,  ,  ,   and  . Entries with these action fields specify the handling of signals received by . An empty runlevels field in a   entry is the same as one containing  , and an empty runlevels field in any of the other kinds of entries is the same as one containing.
 * . Entries with this action type are ignored.

is read and processed by during the boot sequence, immediately before a runlevel change, starting on-demand procedures or entering single user mode, if explicitly requested with a telinit q or telinit Q command, and if  receives a   signal. When is read, if analysis of identifier fields reveals that an entry has been removed or has changed its action field,  kills the corresponding process if it is still running, with the same algorithm used for runlevel changes.

If an  argument is specified in the kernel command line, each time  is processed, for each   kernel parameter it finds,  behaves as if  additionally contained the line:

With ${TERM} replaced by the value of the  parameter, and ${ID} replaced by a string generated from that value. If can't be read to parse the kernel command line, or the value generated for ${ID} matches that of a previous entry (either generated in this way or actually specified in ), this entry is discarded.

The contents of the process field are used by to construct arguments for a POSIX   call in a child process, just as if they were typed in an interactive shell, unless:
 * There is an file and  is not in single user mode. In this case,  spawns a shell child process using the equivalent of a /bin/sh /etc/initscript ${ID} ${RUNLEVEL} ${ACT} '${PROC}' command, with ${ID}, ${RUNLEVEL} and ${ACT} replaced by the contents of the  entry's identifier, runlevels and action field, respectively, and ${PROC} replaced by the contents of the entry's process field, which is passed as a single argument to the shell. This script can be used to augment 's process handling, e.g. controlling the resources available to them with the  utiliy, etc.
 * The process field contains characters that are have special meaning to the shell, like '$', '*', '&', etc., or the initial  call failed because the program's executable file has an unrecognized format. In this case,  spawns a shell child process using the equivalent of a /bin/sh -c 'exec ${PROC}' command, with ${PROC} replaced by the contents of the  entry's process field, which is passed to the shell as part of a single argument after the   option.

starts processes specified in in line order, creating a new session for each of them with a POSIX   call, and redirects their standard input, output and error to the machine' console. Processes specified by  and   entries, as well as processes specified by ,  ,  ,   and   entries while  is in single user mode, run in the foreground process group with the console as their session's controlling terminal. Processes specified by other entries run as the session leader with no controlling terminal. The environment set up by for its child processes is described here.

For further information please consult 's man page.

The boot sequence
These are 's actions at program startup:


 * 1) It sets the the write permission for group and others bits in the file mode creation mask using a POSIX   call, leaving all other file mode bits unmodified.
 * 2) 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).
 * 3) It uses a Linux   system call with a   request, to ask the kernel to send a   signal to process 1 whenever an appropriate key combination is pressed. This key combination, the keyboard signal, is usually configured to be +.
 * 4) It closes its standard input, output and error.
 * 5) It makes itself a session leader using the POSIX   call.
 * 6) It sets the PATH environment variable to.
 * 7) If the file that corresponds to the libc's user accounting database exists (,  for GNU libc), it truncates the file to length 0, otherwise it creates the file with permissions 0644 (i.e. the  command would show  ).
 * 8) If emergency mode was requested, it spawns an emergency shell by invoking the  program. Emergency mode is requested by passing a   option, or an   argument, to  (see later). The shell process runs in the foreground process group of a new session with the console as the controlling terminal, and if it exits, the boot sequence resumes.
 * 9) It reads and processes.
 * 10) It starts all processes that have an  entry with a   action field.  handles them as if the action field was   (see here). This means that  starts processes in the order their corresponding entries appear in, and waits for each of them to finish before starting the next one, so execution of programs specified in   entries must result in a short-lived processes.
 * 11) A boot record (i.e. a   object with  ) is written to the user accounting database, and to the user accounting log file ( for GNU libc, which is not truncated on each reboot). The boot record has   set to "reboot",   set to "",   set to 0 and   set to "~". The record written to the log file also has   set to the operating system's release, as contained in the   field of a   object filled by a POSIX   call.
 * 12) If an   option or an ,   or   argument was passed to , it enters single user mode. If the mode is later left, the boot sequence resumes.
 * 13) It determines a default runlevel. If  contains entries with   action fields, then the runlevels field of the first one in the file specifies the default runlevel. The field must contain a number from 0 to 9 representing a runlevel, or the letters S or s, representing single user mode. If the entry's runlevels field is invalid or if there is no   entry in the file,  asks the user to enter a runlevel on the machine's console. If this fails for any reason, then the default runlevel is single user mode.
 * 14) If the default runlevel is single user mode,  enters it. If single user mode is later left, the boot sequence resumes.
 * 15) It starts all processes that have an  entry with a   or   action field.  handles processes specified by   entries as if the action field was , and processes specified by   entries as if the action field was  . This means that  starts processes in the order their corresponding entries appear in , and, in the case of those specified by   entries, waits for each of them to finish before starting the next one, so execution of programs specified in those entries must result in short-lived processes.
 * 16) If a single character argument representing a number from 0 to 9 was passed as an argument to, it enters the requested runlevel. Otherwise,  enters the default runlevel.

Arguments can be passed to by specifying them in the kernel 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.

If does not exist, is empty or cannot be read,  behaves as if there was an  file containing the single line:

Runlevels
Process assignment to runlevels is specified in the runlevels field of entries with a ,   or   action field. Runlevel membership does not need to be one-to-one, a process can be a member of more than one runlevel. Processes specified by entries with a,  , or   action field are not members of any runlevel.

Processes in a runlevel are started when enters the runlevel. This happens at the end of the boot sequence for a requested or default runlevel, and when the program is invoked with a single character argument specifying a runlevel. For example, runlevel 4 is entered after following command:

Or at the end of the boot sequence if contains the following line:

When a runlevel is entered, writes a runlevel record (i.e. a   object with  ) to the user accounting database ( for GNU libc) and log file ( for GNU libc). The runlevel record has  set to "runlevel",   set to "", and   set to "~". The  field encodes the values  sets environment variables RUNLEVEL and PREVLEVEL to for processes that belong to the entered runlevel (see later). As of sysvinit-2.91, also saves the value of RUNLEVEL to file.

Handling of runlevel processes is done according to the action field of their respective entry:


 * If the action field is set to, the process is respawned it each time it terminates (just like daemontools-style process supervision suites do). The behaviour of  for such processes is therefore similar to the way daemontools behaves for supervised processes started by an  command, or the way systemd behaves for service units that have   and   directives in their corresponding unit file.
 * If the action field is set to, the process is spawned only once, upon entering the runlevel. The behavior of  for such processes is therefore similar to the way daemontools behaves for supervised processes started by an  command, or the way systemd behaves for service units that have   and   directives in their corresponding unit file.
 * If the action field is set to, the process is spawned only once, upon entering the runlevel, and  waits for it to finish execution, before starting the next process. The behaviour of  for such processes is therefore similar to the way systemd behaves for service units that have   and   directives in their corresponding unit file.

If execution of a process specified by a  entry is restarted 10 times in less than 2 minutes, it is considered to be failing, and is not respawned again until 5 minutes have elapsed. Because waits for processes specified by   entries to finish their execution, only programs that result in short-lived processes when executed are suitable for such entries.

The environment set up by for each child process contains:


 * Environment variables set by the kernel for process 1.
 * Variables PATH set to  and SHELL set to.
 * Variables INIT_VERSION set to, with ${version} replaced by the package's version, CONSOLE set to the pathname of console device node used by , RUNLEVEL set to the current runlevel, or to S if in single user mode, and PREVLEVEL set to the previous runlevel (left when entering the current one), or to "S" if the current runlevel was entered after leaving single user mode, or to "N" if the current runlevel was entered after the boot sequence.
 * Environment variables that have been added by use of the program with   options. A telinit -e VAR=newvalue command adds a variable named VAR to the environment and sets its value to newvalue, removing the variable first if it already existed. A telinit -e VAR command removes a variable named VAR from the environment, that was added with a previous  command. Requests to add variables with names that do not begin with INIT_ are ignored. A maximum of 16 environment variables can be added this way.

Changing the runlevel makes reread, determine all previously spawned processes that are still running and do not belong to the new runlevel, according to the runlevels field of their corresponding (possibly updated) entry, and then kill all processes in their process group with a signal. first sends a  signal, then waits for a grace period, and finally sends a   signal if any of the process group leaders is still alive. sets the duration of the grace period to 5 seconds at program startup (3 seconds as of version 2.92), but it can be changed to a different value each time is invoked, by passing it a   option followed by a new time value in seconds. This value is used until the next command received by on its control FIFO updates it. For example, to change to runlevel 2, and also set a grace period of 10 seconds between  and , the following command can be used:

Processes that belong to both the previous and current runlevels are left alone. When performing a runlevel change, does not kill processes specified by   entries that are still running. Each time spawns a child process, it writes an init process record (i.e. a   object with  ) to the user accounting database and log file, and each time a child process that  spawned terminates,  writes an terminated process record (i.e. a   object with  ) to the user accounting database and log file. These records have empty  and   fields,   set to the contents of the corresponding  entry's identifier field, and   set to the process' process ID (PID). No init process and terminated process records are written to the user accounting database and log file if the process field of the entry starts with a plus sign ('+').

Runlevel, init process and terminated process records written to the log file also have the  field set to the operating system's release, as contained in the   field of a   object filled by a POSIX   call. The contents of the user accounting database and log file can be seen with the program, see.

Ondemand procedures
supports the definition of sets of processes that can be launched by explicit use of the program. These sets of processes are called ondemand procedures. Up to three sets of processes can be defined, identified by letters A, B and C. Their member processes are specified in entries that contain an A, B or C character, or its lowercase form, in the runlevels field. A telinit a, telinit b or telinit c command, respectively, or a telinit A , telinit B or telinit C command, respectively, starts (or restarts) all processes in the set that are not currently running. rereads whenever  is invoked in this way, so that it can pick up updated entries.

Processes configured to be in the A, B or C set can have entries with a ,   or   action field. They can also have an  action field, which  treats it as if it was a   action. After a invocation that specifies their ondemand procedures set, these processes are not killed by  when performing a runlevel change, but are if single user mode is entered, unless their  entry also marks them as valid for that mode.

Ondemand procedures can not be started in single user mode or during the boot sequence.

Single user mode
Single user mode is an execution mode supported by, that is similar to a runlevel: upon entering this mode starts a set of processes that are configured in  to be valid for it and not currently running, and kills all other configured processes that are still running, except those specified by   entries, with the same algorithm used for runlevel changes.

Processes valid for single user mode are those with an entry that contains an S or s character in its runlevels field. If does not contain entries marked as valid for single user mode,  behaves as if the file contained the following additional entry:

This entry makes init spawn an emergency shell by invoking the program when entering single user mode.

enters single user mode:


 * During the machine's boot sequence, if requested to do so in the kernel command line, after starting all processes specified by  entries,
 * If the default runlevel determined during the boot sequence is single user mode, after starting all processes specified by  entries but before starting all processes specified by   and   entries, or
 * If a telinit s or telinit S command is used.

Single user mode is left when either a runlevel change is requested using, or when all processes marked as valid for single user mode exit and are not configured to be restarted (e.g. all their entries have  and   action fields). In the latter case, either the boot sequence continues with the processing of 's  and   entries, or the default runlevel is determined again with the same algorithm that is used during the boot sequence, and  enters it.

Signal processing
responds to received signals in the following ways:


 * : forces to reexamine its configuration file,.
 * : makes start the process specified by the first active  entry with a   action field. This signal is sent by the kernel when the ++ key combination is pressed.  handles the specified process as if the entry's action field was.
 * : makes start the process specified by the first active  entry with a   action field. This signal is sent by the kernel when the key combination that corresponds to keyboard signal is pressed (usually configured to be +).  handles the specified process as if the entry's action field was.
 * : makes close and reopen its control FIFO,  ( for sysvinit version 2.88).
 * : makes close its control FIFO. This may be used to make sure  is not holding open any files, but also prevents it from receiving commands from . The FIFO can be reopened by sending  the   signal.
 * : used by for its power failure and restoration routines.

supports communication with programs that are able to monitor the machine's power supply status (e.g. an uninterruptible power supply management program). If such a program can be configured to write to file (formerly ) and send process 1 a   signal,  can take actions depending on the reported status. When receives a   signal, it reads the first character of file :
 * If it is a character other that O or L (conventionally F for "fail"), it considers the power to be failing and that there might be a need to shut down soon, and starts all processes specified by active entries with   and   action fields.
 * If it is an L character (for "low"), it considers the power supply to be in low battery state and that inminent shutdown is needed, and starts all processes specified by active entries with a   action field.
 * If it is an O character (for "OK"), it considers the power supply to be restored to normal status and that there is no longer an need to shut down, and starts all processes specified by active entries with a   action field.

handles processes specified by,   and   entries as if the action field was  , and processes specified by   entries as if the action field was. removes after reading it. Usage of this file and the  signal is discouraged in favor of sending ,   and   commands on 's control FIFO (as defined in , see ).

A,  ,  ,  ,   or   entry is considered active if its runlevels field includes the current runlevel, or contains either S  or s and  is in single user mode.

init re-execution
is capable of re-executing itself. This is similar to systemd's command, and mostly useful after a package upgrade, to have a new version of  execute as process 1 without a complete machine reboot, provided the new version is sufficiently compatible with the mechanism used by the running version for re-execution.

Re-execution is triggered with a telinit u or telinit U command. When asked to do this, spawns a child process with a pipe connected to it, the state pipe, that the child uses to transmit back an encoding of 's execution state, as well as of the configuration and state of all processes configured in. Process 1 then uses a POSIX   call to perform the re-execution, including in the environment passed to the call all variables set by  commands. At program startup, the new process image detects whether it has an open file description that corresponds to the reading end of the state pipe or not, and if it does, it reads the encoded state of the previous process image from the pipe, adjusts its own state, and arranges to appear, from the perspective of its externally observable behaviour, as if it resumed execution from the point the previous process image was at before the  call (e.g. the boot sequence is not performed again, no runlevel change happens, single user mode is not left, etc.).

halt, poweroff, and reboot
The, and  programs halt the machine, power it off and reboot it, respectively. The program also behaves as  if invoked with a   option.

Unless they are invoked with an  option, these programs check the current runlevel. If the INIT_VERSION and RUNLEVEL variables are set in the environment (which would happen if they are executed because they are configured in ), the current runlevel is taken to be the value of RUNLEVEL. Otherwise, they search the user accounting database ( for GNU libc) for the most recent runlevel record (i.e. a  object with  ) and decode the current runlevel from its   field. If searching the user accounting database fails or returns nothing, the runlevel is read from. If the runlevel is neither 0 nor 6, they replace themselves with the program (see later), using a POSIX   call. and perform the equivalent of a shutdown -h now action, and, the equivalent of a shutdown -r now action. If they are invoked with a  option followed by a time value in seconds, they pass them unmodified to the  program.

If, , and are invoked with an   ("force") option, or they are invoked in runlevels 0 or 6, they write a shutdown record to the user accounting log file ( for GNU libc). The shutdown record is a runlevel record that has   set to "shutdown",   and   set to "",   set to 0, and   set to the operating system's release, as contained in the   field of a   object filled by a POSIX   call. Then, unless they have been invoked with an  ("no sync") option, they sync all disks, flushing all the dirty system buffers, using the POSIX   call. And finally, they flush the cache of all hard disks using a Linux  system call with a   request (specifying   or  ), and perform their respective shutdown action using the Linux   system call.

Gentoo's patched program also accepts a   ("kexec") option, which makes it reboot the machine using a kernel kexec boot instead of a standard system boot. This works if the kernel is configured with kexec support:

If the kexec boot fails, falls back to a standard system boot. A command can only be used if invoked in runlevel 6, or if   is also specified.

If, , and are invoked with an   ("ifdown") option, they also shut network interfaces down using a Linux   system call with a   request to clear each interface's   flag (see ). If they are invoked with an  ("hddown") option, they put all hard disks in standby mode after flushing their cache, using using a Linux   system call with a   request (specifying   and  ). If they are invoked with a  option, they only write the shutdown record to the user accounting log file, without actually shutting the machine down. This option can be combined with  and. If they are invoked with a  option, no shutdown record is written to the user accounting log file (  implies  ).

For more information on, and , please consult their respective man pages.

shutdown
The program is a generic program for shutting the machine down. It accepts options, a time specification, and an optional message to be shown to logged in users. The time specification is used to delay actual shutdown, it can be a nonzero time value in minutes, optionally preceded by a plus sign ('+'), it can have the form  or   to specify clock time (in 24-hour form and local time, e.g. shutdown -r 4:30 or shutdown -r 22:13 ), or it can be the word now. In the first case, machine shutdown is initiated after the specified time has elapsed, in the second case, it is initiated at the specified clock time, and in the latter case, it is initiated immediately. shutdown 0 is valid and equivalent to shutdown now.

does not exit, it writes a PID file with its process ID and waits the requested amount of time, displaying the specified message, if any, to logged in users in the same way that the program (from package util-linux, ) does, with an increasing frequency as the scheduled shutdown approaches. The PID file is. Within the last 5 minutes until the scheduled shutdown, the program also writes a message in file, warning that the system is going down. This file instructs the program to prevent non-root users from logging in. If is invoked and it finds  exists and contains a valid process ID (probed using a POSIX   call with a null signal, 0), it exits with a "shutdown: already running" error. If is invoked with a   option ("cancel"), no time specification, and an optional message, it cancels a pending shutdown request by sending a   signal to the process with the PID read from, and displays the specified message, if any, to logged in users.

changes the working directory to, waits the requested amount of time and, unless it was invoked with the  option, sends a message to a syslog server, if available, announcing that the system is shutting down, using the libc's implementation (i.e. that of the POSIX  ,   and   calls), and initiates shutdown. 's message specify facility  and severity. If was invoked without the   option, it removes the  and  files, syncs all disks, flushing all the dirty system buffers, using the POSIX   call, and finally replaces itself with the  program to change the runlevel, using a POSIX   call. The program from upstream's package performs the equivalent of a  action if it is invoked with an   option, the equivalent of a  action if it is invoked with an   option, and the equivalent of a  action if it is invoked with neither of these options, which means that  will do whatever  specifies for those runlevels. Therefore, entering runlevel 0 is customarily expected to either halt or power the machine off, entering runlevel 6 is customarily expected to reboot the machine, and runlevel 1 is customarily expected to be some kind of 'maintenance mode'. If an  option is passed together with ,  additionally performs the equivalent of a  action before the   call, and if a   option is passed together with  ,  additionally performs the equivalent of a  action before the   call (corrected to  in version 2.92 to match the man page). This allows runlevel 0 processes to use the value of the INIT_HALT environment variable to determine whether a halt or poweroff operation was requested. can also be invoked with a  option, followed by a single character that is passed as 's argument, and with a   option followed by a time value in seconds, that are passed unmodified to. Only 0, 1, 5, 6, A, B, C, S, a, b, c, and s are valid after.

Gentoo's patched program simplifies usage according to the following table:

If is invoked with a   option, it only displays the specified message, if any, to logged in users while waiting the requested amount of time, but doesn´t actually shut the machine down. If it is invoked with a  option, it creates file, a convention for asking the rc subsystem to skip checking filesystems with  after next boot, and if it is invoked with a   option, it creates file , a convention for asking the rc subsystem to make  check filesystems after next boot, even if they are marked clean, by passing it a special 'force' option. OpenRC's service, for instance, follows this convention. Cancelling a pending shutdown with the  option removes files, ,  and.

If is invoked with an   option, it looks up all logged in users in a list contained in file. If there is a match, or if root is logged in, shutdown is allowed to proceed. Otherwise, a "shutdown: no authorized users logged in" error is displayed. The list of logged in users is obtained by reading login records from the user accounting database. is a text file that contains one account name per line. Lines that start with a '#' character are treated as comments and ignored. The mechanism can be used as a way of limiting the ability of logged in users to trigger a machine reboot by pressing the ++ key combination, if  is executed as a result because it is specified in an    entry (see here).

Finally, if is invoked with a   option, it performs the machine shutdown itself instead of delegating it to runlevel processes. This option can only be used in combination with options,  ,   and  , or option   if it names runlevels 0 or 6, and its use is discouraged. In this case:


 * 1) It kills all processes, first by sending a   signal using a   call, then waiting for a grace period, and finally sending a   signal. The duration of the grace period is the time value passed with the   option, if any (which in this case is interpreted by  instead of being passed to ), or 3 seconds if there is no   option.
 * 2) It writes a shutdown record to the user accounting log file, just like,  or.
 * 3) It disables process accounting by invoking the  program (ignoring failures if it is not present).
 * 4) It turns filesystem quotas off using a  command (ignoring failures if the  program is not present).
 * 5) It syncs all disks, flushing all the dirty system buffers, using the POSIX   call,
 * 6) It disables devices and files for paging and swapping using a  command,
 * 7) It unmounts all filesystems named in  using a  command,
 * 8) It reboots the machine if it was invoked with   or , or halts the machine otherwise, using the Linux   system call.

For more information please consult the man page.

bootlogd
is a daemon that logs output sent by processes to, to a log file in the filesystem, and can be used as a boot sequence logger. It does so by opening a pseudo-terminal master and slave device pair using the libc's  function (and falling back to trying to open legacy BSD-like device pairs  and,  and , etc. if   fails), using a Linux   system call with a   request to perform console redirection to the pseudo-terminal slave, and then reading from the pseudo-terminal master and logging read messages to the log file, prepended with a timestamp. The pathname of the log file can be specified after an  option, otherwise it defaults to. If the logfile is not accessible, the messages will be buffered in memory until it is (possibly after mounting some filesystem, which prevents from creating the file under a mount point). If a  option ("create") is passed to, the logfile is created if it does not exist. opens the log file for appending; if it is passed a  option ("rotate"), it will rename the current logfile, adding a tilde ('~') after the name (e.g. ), and create a new one instead.

also tries to display read messages on the actual machine console, using the POSIX  call with a file descriptor obtained by opening a suitable device node. It parses the kernel command line, and if a  kernel parameter was specified,  tries to use its value as the device node's pathname. If that fails or there is no  parameter, it tries a sequence of default device node pathnames (,, and others).

forks a child process and exits, optionally writing a PID file with the child's process ID if a  option is passed followed by the file's pathname. The child process is the long-lived one that does the actual logging, for compatibility with rc subsystems that expect that behavior from daemons (like OpenRC's program). The forking can be prevented by passing a  option (e.g. for use with daemontools-style process supervision suites, OpenRC's  program, or configuring it in  so that it is launched directly by ).

uses the POSIX  call after writing every newline-terminated line to the log file; if it is passed an   option, it also follows this with a POSIX   call, to ensure that the data is written to the file.

For more information please consult the man page.

Other utilities
The program sends a signal to all processes except itself, process 1, and all processes in its session, so that if it is called from a shell script, it won't kill the shell process that is running the script. It does so by reading all process subdirectories of (i.e. subdirectories that have names that correspond to process IDs) to get a list of processes, mounting the   filesystem if necessary with a mount -t proc proc /proc command, and then sends each of them the specified signal one by one. takes a signal number as an argument, optionally preceded by a hyphen ('-'); if invoked with no argument, it sends a  signal.

determines each process' session ID, and whether it is a zombie or kernel thread (so that it can be skipped), by reading the corresponding file. It prints error messages on its standard error if its standard input is a terminal, and to a syslog server otherwise, using facility  (and falling back to the machine's console by using a POSIX   call with the   flag). If it is invoked with a sequence of one or more  ("omit") options followed by a comma-separated list of process IDs, corresponding processes are not sent the specified signal.

used to be called by OpenRC's service until version 0.27, when it was replaced by internal program.

The program prints the previous and current runlevels on its standard output. It does so by decoding them from the  field of the most recent runlevel record (i.e. a   object with  ) in the user accounting database. The pathname of the file that corresponds to the database can optionally be specified as an argument, otherwise, uses the libc's default one ( for GNU libc). If searching the user accounting database fails or returns nothing, the current runlevel is read from, and the previous runlevel is displayed as "N". If that fails as well, prints "unknown".

The program can be used to invoke another program with arguments that might have character escape sequences that use the  file's encoding convention, i.e. '\011' representing a TAB character, '\040' representing a space character, '\\' or '\134' representing a backslash ('\'), etc. (see ). It accepts a program name or its pathname, followed by the program's arguments. replaces replaces itself with the specified program using a POSIX  call, passing the supplied arguments to it with any escape sequence replaced by its corresponding character. Generally, this is only useful if 's arguments are generated from the contents of (e.g. by using the  utility).

For more information on, or , please consult their respective man page.

Gentoo's sysvinit setup
Gentoo's sysvinit setup, as specified in its standard file, is as follows:


 * The default runlevel is 3. This is specified in an  entry.
 * executes an command during the boot sequence and waits for it to finish. This is specified in a   entry, and makes OpenRC start services in its   runlevel.
 * then executes an command and waits for it to finish. This is specified in a   entry, and makes OpenRC start services in its   runlevel.
 * Entering runlevel 1 makes execute an  command and wait for it to finish, then spawn an  process for terminal . The  invocation makes OpenRC stop all its managed services except those in its   runlevel.
 * Entering runlevel 2 makes execute an  command and wait for it to finish, then spawn  processes for terminals  to . The  invocation makes OpenRC start services in its   runlevel.
 * Entering runlevel 3 makes execute an  command and wait for it to finish, then spawn  processes for terminals  to . The  invocation makes OpenRC start services in its   runlevel.
 * Runlevels 4 and 5 are identical to runlevel 3.
 * Entering runlevel 0 makes re-execute itself, then execute an  command and wait for it to finish, then power the machine off with a  command. The  invocation makes OpenRC start services in its   runlevel.
 * Entering runlevel 6 makes re-execute itself, then execute an  command and wait for it to finish, then reboot the machine with a  command. The  invocation makes OpenRC start services in its   runlevel, and set variable RC_REBOOT to "YES" in the environment of executed service scripts. This allows services to use RC_REBOOT to determine whether a reboot operation was requested or not.
 * Entering single user mode makes execute an  command and wait for it to finish, then spawn an emergency shell by invoking the  program.
 * Using a telinit a command makes execute the  script. This is specified in a   entry, and used by OpenRC service script  from package  to launch a display manager. Script  is provided by package.
 * Pressing the ++ key combination makes reboot the machine with a  command. This is specified in a   entry.

process are specified in  entries, so that when a user's interactive shell exits, it is possible to log in again on the terminal the shell used. The Gentoo ebuild might also add architecture-specific entries to, to make spawn additional  processes for special character device nodes.