inittab(4)inittab(4)NAMEinittab - script for the init process
The /etc/inittab file supplies the script to init's role as a general
process dispatcher. The process that constitutes the majority of init's
process dispatching activities is the line process /etc/getty that
initiates individual terminal lines. Other processes typically
dispatched by init are daemons and the shell.
The inittab file is composed of entries that are position dependent and
have the following format:
Each entry is started with a character other than # and ended by a
newline. Lines starting with # are ignored. A backslash (\) preceding a
newline indicates a continuation of the entry. Up to 512 characters per
entry are permitted. Comments can be inserted in the process field using
the sh(1) convention for comments. Comments in the process field of
lines that spawn gettys are displayed by the who(1) command. Such
process field comments can contain information about the line such as its
location. There are no limits (other than maximum entry size) imposed on
the number of entries within the inittab file. The entry fields are:
id This field, of up to four characters, is used to uniquely
identify an entry.
rstate This defines the run-level in which this entry is to be
processed. Run-levels effectively correspond to a
configuration of processes in the system. That is, each
process spawned by init is assigned a run-level or run-levels
in which it is allowed to exist.
The run-levels are represented by the letter s (or S), or a
number ranging from 0 through 6. As an example, if the system
is in run-level 1, only those entries having a 1 in the rstate
field are processed.
When init is requested to change run-levels, all processes that
do not have an entry in the rstate field for the target run-
level are sent the warning signal (SIGTERM) and allowed a grace
period (see init(1M) for the length of this grace period),
before being forcibly terminated by a kill signal (SIGKILL).
The rstate field can define multiple run-levels for a process
by selecting more than one run-level in any combination from
0-6, s, and S. If no run-level is specified, the process is
assumed to be valid at all run-levels.
There are three other values, a, b, and c, that can appear in
the rstate field, even though they are not true run-levels.
Entries that have these characters in the rstate field are
processed only when the telinit (see init(1M)) process requests
them to be run (regardless of the current run-level of the
system). They differ from run-levels in that init can never
enter run-level a, b, or c. Also, a request for the execution
of any of these processes does not change the current run-
level. Furthermore, a process started by an a, b, or c command
is not killed when init changes levels. They are only killed
if their line in /etc/inittab is marked off in the action
field, their line is deleted entirely from /etc/inittab, or
init goes into the SINGLE USER state.
action Key words in this field tell init how to treat the process
specified in the process field. The actions recognized by init
are as follows:
respawn If the process does not exist then start the
process. Do not wait for its termination
(continue scanning the inittab file) and when it
dies restart the process. If the process
currently exists then do nothing and continue
scanning the inittab file.
wait Upon init's entering the run-level that matches
the entry's rstate, start the process and wait for
its termination. All subsequent reads of the
inittab file while init is in the same run-level
causes init to ignore this entry.
once Upon init's entering a run-level that matches the
entry's rstate, start the process, do not wait for
its termination. When it dies, do not restart the
process. If upon entering a new run-level, the
process is still running from a previous run-level
change, the program is not restarted.
boot The entry is to be processed only at init's boot-
time read of the inittab file. init is to start
the process and not wait for its termination.
When it dies, init does not restart the process.
In order for this instruction to be meaningful,
the rstate should be the default or it must match
init's run-level at boot time. This action is
useful for an initialization function following a
hardware reboot of the system.
bootwait The entry is to be processed the first time init
goes from single-user to multi-user state after
the system is booted. (If initdefault is set to
2, the process runs right after the boot.) init
starts the process, waits for its termination and,
when it dies, does not restart the process.
powerfail Execute the process associated with this entry
only when init receives a power fail signal
(SIGPWR, see signal(2)).
powerwait Execute the process associated with this entry
only when init receives a power fail signal
(SIGPWR) and wait until it terminates before
continuing any processing of inittab.
off If the process associated with this entry is
currently running, send the warning signal
(SIGTERM) and wait 20 seconds before forcibly
terminating the process via the kill signal
(SIGKILL). If the process is nonexistent, ignore
ondemand This instruction is really a synonym for the
respawn action. It is functionally identical to
respawn but is given a different keyword in order
to divorce its association with run-levels. This
is used only with the a, b or c values described
in the rstate field.
initdefault An entry with this action is only scanned when
init initially invoked. init uses this entry, if
it exists, to determine which run-level to enter
initially. It does this by taking the highest
run-level specified in the rstate field and using
that as its initial state. If the rstate field is
empty, this is interpreted as 0123456 and so init
enters run-level 6. Additionally, if init does
not find an initdefault entry in /etc/inittab, it
requests an initial run-level from the user at
sysinit Entries of this type are executed before init
tries to access the console (before the Console
Login: prompt). It is expected that this entry
will be used only to initialize devices on which
init might try to ask the run-level question.
These entries are executed and waited for before
process This is a sh command to be executed. The entire process field
is prefixed with exec and passed to a forked sh as sh -c 'exec
command'. For this reason, any legal sh syntax can appear in
the process field. Comments can be inserted with the
; #comment syntax.
SEE ALSOgetty(1M), init(1M), sh(1), who(1), exec(2), open(2), signal(2).