inittab(4) File Formats inittab(4)NAMEinittab - script for init
DESCRIPTION
The /etc/inittab file controls process dispatching by init. The pro‐
cesses most typically dispatched by init are daemons.
It is no longer necessary to edit the /etc/inittab file directly.
Administrators should use the Solaris Service Management Facility (SMF)
to define services instead. Refer to smf(5) and the System Administra‐
tion Guide: Basic Administration for more information on SMF.
To modify parameters passed to ttymon(1M), use svccfg(1M) to modify the
SMF repository. See ttymon(1M) for details on the available SMF proper‐
ties.
The inittab file is composed of entries that are position dependent and
have the following format:
id:rstate:action:process
Each entry is delimited by a newline; however, a backslash (\) preced‐
ing a newline indicates a continuation of the entry. Up to 512 charac‐
ters for each entry are permitted. Comments may be inserted in the
process field using the convention for comments described in sh(1).
There are no limits (other than maximum entry size) imposed on the num‐
ber of entries in the inittab file. The entry fields are:
id
One to four characters used to uniquely identify an entry. Do not
use the characters "r" or "t" as the first or only character in
this field. These characters are reserved for the use of rlogin(1)
and telnet(1).
rstate
Define 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(s) in which it is allowed to exist. The run levels are repre‐
sented by a number ranging from 0 through 6. For 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 5-second grace period
before being forcibly terminated by the 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 through
6. If no run level is specified, then the process is assumed to be
valid at all run levels 0 through 6.
There are three other values, a, b and c, which can appear in the
rstate field, even though they are not true run levels. Entries
which have these characters in the rstate field are processed only
when an init or telinit process requests them to be run (regardless
of the current run level of the system). See init(1M). These 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 killed only if their line in inittab is marked off in the
action field, their line is deleted entirely from inittab, or init
goes into single-user state.
action
Key words in this field tell init how to treat the process speci‐
fied 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 the process dies, restart the process. If the process
currently exists, do nothing and continue scanning the inittab
file.
wait
When init enters 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
cause init to ignore this entry.
once
When init enters 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 init enters a new run
level and 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, it 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 fol‐
lowing a hardware reboot of the system.
bootwait
The entry is to be processed the first time init goes from sin‐
gle-user to multi-user state after the system is booted. 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(3C)).
powerwait
Execute the process associated with this entry only when init
receives a power fail signal, SIGPWR, and wait until it termi‐
nates before continuing any processing of inittab.
off
If the process associated with this entry is currently running,
send the warning signal SIGTERM and wait 5 seconds before
forcibly terminating the process with the kill signal SIGKILL.
If the process is nonexistent, ignore the entry.
ondemand
This instruction is really a synonym for the respawn action.
It is functionally identical to respawn but is given a differ‐
ent keyword in order to divorce its association with run lev‐
els. This instruction is used only with the a, b or c values
described in the rstate field.
sysinit
Entries of this type are executed before init tries to access
the console (that is, before the Console Login: prompt). It is
expected that this entry will be used only to initialize
devices that init might try to ask the run level question.
These entries are executed and init waits for their completion
before continuing.
process
Specify a command to be executed. The entire process field is pre‐
fixed 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.
SEE ALSOsh(1), who(1), init(1M), svcadm(1M), svc.startd(1M), ttymon(1M),
exec(2), open(2), signal(3C), smf(5)
System Administration Guide: Basic Administration
NOTES
With the introduction of the service management facility, the system-
provided /etc/inittab file is greatly reduced from previous releases.
The initdefault entry is not recognized in Solaris 10. See smf(5) for
information on SMF milestones, and svcadm(1M), which describes the
"svcadm milestone -d" command; this provides similar functionality to
modifying the initdefault entry in previous versions of the Solaris OS.
SunOS 5.10 9 Dec 2004 inittab(4)
