inittab(4) DG/UX R4.11 inittab(4)
NAME
inittab - script for init
DESCRIPTION
The file /etc/inittab controls process dispatching by init. The
processes most typically dispatched by init are servers.
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 per 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 This is one or two characters 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 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
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). 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 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 the first time
init goes to the specified rstate (if rstate
is the default the first time init goes to
states 1, 2, 3, or 4). init is to start the
process, not wait for its termination; when
the process dies, init will not restart it.
In order for this instruction to be
meaningful, the rstate should either not be
specified (states 1, 2, 3, or 4), 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 bootwait action is similar to the boot
action with the exception that init waits for
boot action to terminate before init starts
to process further commands. When the
bootwait action dies, init 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 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.
initdefault An entry with this action is scanned only
when init is 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 which will allow the system
to come up and using that as its initial
state. If the rstate field is empty or will
not allow the system to come up or init does
not find an initdefault entry in inittab, it
requests an initial run level from the user
at reboot time.
sysinit Entries of this type are executed before init
tries to access the console (i.e., before the
Console Login: prompt). It is expected that
this entry will be only used to initialize
devices on which init might try to ask the
run level question. These entries are
executed and waited for before continuing.
trustedcon There should only be one entry of this type
which will specify the console login program.
This entry causes the login program to run on
the console (and thus require a password) at
singleuser level as well as other levels. No
rstate should be specified with trustedcon.
trustedonce These entries will be executed once only when
the system is initially booted even if it is
booted to singleuser level. No rstate should
be specified with trustedonce.
trustedrespawn
These entries will be executed once when the
system is initially booted and will be
respawned if they die. No rstate should be
specified with trustedrespawn.
trustedwait These entries will be executed once only when
the system is initially booted. init will
wait until the specified process has
completed. If the specified process exits
with a status equal to zero, then init will
proceed normally. If the specified process
exits with a status not equal to zero, init
will write a warning message and bring the
system to single-user mode. init will not
permit the user to proceed to a higher init
level after a trustedwait process has
failed. The user should then correct
whatever caused the specified process to fail
and reboot the system. This entry can be
used to ensure that a particular action has
completed successfully (such as starting
auditing) prior to proceding to multiuser
mode. No rstate should be specified with
trustedwait.
process This is 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.
NOTES
WARNING: Due to the mechanisms in place to help protect the login
mechanism, /dev/console cannot be held open by any
processes not associated with the login session. If it is
held open, then you will only be able to login to the
console for one session. After the first session
terminates, no more sessions will be allowed. login will
issue the message "System problem, please see you
administrator". If it is required that the console be
held open, then use /dev/syscon. The most appropriate
mechanism to use to display error and status information on
the console is syslog.
SEE ALSO
init(1M), ttymon(1M), exec(2), open(2), signal(2)
sh(1), who(1)
Licensed material--property of copyright holder(s)