script for the init process
The 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
The inittab file is recreated automatically by idmkinit
at boot time anytime the kernel has been reconfigured.
To construct a new inittab file,
idmkinit concatenates the device driver init files in
/etc/conf/init.d onto the end of /etc/conf/init.d/kernel
(the default inittab).
If you add an entry directly to inittab,
the change exists only until the kernel is relinked.
To add an entry permanently, you must also edit
The kernel file has the same format as inittab.
The inittab file is composed of entries that are position-dependent.
Each entry is delimited by a new-line; however, a
backslash (\) preceding a new-line 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.
Comments for lines that spawn gettys are displayed by the
command. It is expected that they will contain some information
about the line such as the location.
There are no limits (other than maximum entry size) imposed on the number
of entries within the inittab file.
The four fields per entry in inittab or
This is up to four characters used to uniquely identify an entry.
This defines the run-level in which this entry is to be processed.
Each process spawned by init
is assigned one or more run-levels in this field
at which it is allowed to exist.
The run-levels are represented by the numbers from 0
through 6, and the letters S or s
init processes the
entries which have a 2 (or no specified run-level)
in this field when the system goes to run-level 2,
If no run-level is specified, the process is assumed to be valid at
When the system first goes to single-user mode after being rebooted
init only invokes entries
which specify sysinit in their action field.
Entries which specify (or imply) that they should be run when the
system goes to single-user mode are only invoked when the system
subsequently enters this run-level from one of run-levels 1 through 6.
When init changes run-levels, it
sends SIGTERM to processes
which do not have an entry in this field for the target
run-level (but not those without any entry).
init allows these processes 20 seconds to die
before being forcibly terminating them using SIGKILL.
Entries with values a, b, and
c in this field are not true run-levels but
are processed only when
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.
In addition, a process started by an a, b, or
c command is not killed when init
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
Key words in this field tell init how to treat the process
specified in the process field.
init recognizes the following actions:
The entry is to be processed only at init's boot-time read of the
init is to start the process, not wait for its termination;
and when it dies, 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.
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 will run right after the boot.)
init starts the process, waits for its termination and,
when it dies, does not restart the process.
An entry with this action is only scanned when init is
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, it is interpreted as
0123456 and so init will enter run-level 6.
Additionally, if init does not find an initdefault
entry in /etc/inittab, then it will request an initial
run-level from the user at reboot time.
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
If the process is nonexistent, ignore the entry.
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, where the process is still running from a
previous run-level change, the program will not be restarted.
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
This is used only with the a, b, or c
values described in the rstate field.
Execute the process associated with this entry only when init
receives a power fail signal (SIGPWR; see
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
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
init executes these entries when the system first goes to
single-user mode after being rebooted. It does not execute these
entries if the system is subsequently put in single-user mode from
any of run-levels 1 through 6. Entries with sysinit in their
action field do not specify a run-level in their
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 will cause init to ignore this entry.
This is a command to be executed by
The entire process
field is passed to a forked sh to be run by
For this reason, any legal sh syntax can appear in the
process field. Comments can be inserted with the
; #comment syntax.
The SCO OpenServer Release 6.0.0 /etc/inittab file
is now sourced from /etc/conf/init.d/kernel
instead of the /etc/conf/cf.d/init.base
file that was used on SCO OpenServer Release 5 systems.
Do not add identical entries to
the /etc/conf/init.d/ files
or duplicate entries will result in /etc/inittab.
base inittab entries for the operating system
inittab entries for added modules and devices
inittab file built by the operating system
© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 03 June 2005