INITTAB(5) File Formats and Configurations INITTAB(5)

NAME

inittab - script for init

DESCRIPTION

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(7) and the System
Administration Guide: Basic Administration for more information on
SMF.


To modify parameters passed to ttymon(8), use svccfg(8) to modify the
SMF repository. See ttymon(8) for details on the available SMF
properties.


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 (\)
preceding a newline indicates a continuation of the entry. Up to 512
characters 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 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 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
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(8). 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
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. 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 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 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.

SEE ALSO

sh(1), who(1), exec(2), open(2), signal(3C), smf(7), init(8),
svc.startd(8), svcadm(8), ttymon(8)


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(7) for
information on SMF milestones, and svcadm(8), which describes the
"svcadm milestone -d" command; this provides similar functionality to
modifying the initdefault entry in previous versions of the Solaris
OS.

December 9, 2004 INITTAB(5)