inittab(4) File Formats inittab(4)
inittab - script for init
The /etc/inittab file controls process dispatching by init. The processes 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 Administration Guide: Basic Administration for more information on
To modify parameters passed to ttymon(1M), use svccfg(1M) to modify the SMF repository.
See ttymon(1M) for details on the available SMF properties.
The inittab file is composed of entries that are position dependent and have the following
Each entry is delimited by a newline; however, a backslash (\) preceding a newline indi-
cates a continuation of the entry. Up to 512 characters for each entry are permitted. Com-
ments 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 number 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 char-
acters "r" or "t" as the first or only character in this field. These charac-
ters 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 effec-
tively 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 represented 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 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
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 following a hard-
ware 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. 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 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 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 different keyword
in order to divorce its association with run levels. This instruc-
tion is used only with the a, b or c values described in the
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 continu-
process Specify a 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.
sh(1), who(1), init(1M), svcadm(1M), svc.startd(1M), ttymon(1M), exec(2), open(2), sig-
System Administration Guide: Basic Administration
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 pro-
vides similar functionality to modifying the initdefault entry in previous versions of the
SunOS 5.11 9 Dec 2004 inittab(4)