inittab - format of the inittab file used by the sysv-compatible init process
The inittab file describes which processes are started at bootup and
during normal operation (e.g. /etc/init.d/boot, /etc/init.d/rc, gettys...).
Init(8) distinguishes multiple runlevels, each of which can have
its own set of processes that are started. Valid runlevels are
0-6 plus A, B, and C for ondemand
entries. An entry in the inittab file has the following format:
id:runlevels:action:process
Lines beginning with `#' are ignored.
- id
- is a unique sequence of 1-4 characters which identifies an entry in
inittab (for versions of sysvinit compiled with the old
libc5 (< 5.2.18) or a.out libraries the limit is 2 characters).
Note: traditionally, for getty and other login processes, the
value of the id field is kept the same as the suffix of the
corresponding tty, e.g. 1 for tty1. Some ancient login
accounting programs might expect this, though I can't think of any.
- runlevels
- lists the runlevels for which the specified action should be taken.
- action
- describes which action should be taken.
- process
- specifies the process to be executed. If the process field starts with a
`+' character, init will not do utmp and wtmp accounting for that
process. This is needed for gettys that insist on doing their own
utmp/wtmp housekeeping. This is also a historic bug.
The runlevels field may contain multiple characters for
different runlevels. For example, 123 specifies that the process
should be started in runlevels 1, 2, and 3. The runlevels for
ondemand entries may contain an A, B, or C. The
runlevels field of sysinit, boot, and bootwait
entries are ignored.
When the system runlevel is changed, any running processes that
are not specified for the new runlevel are killed, first with SIGTERM, then
with SIGKILL.
Valid actions for the action field are:
- respawn
- The process will be restarted whenever it terminates (e.g. getty).
- wait
- The process will be started once when the specified runlevel is entered
and init will wait for its termination.
- once
- The process will be executed once when the specified runlevel is
entered.
- boot
- The process will be executed during system boot. The runlevels
field is ignored.
- bootwait
- The process will be executed during system boot, while init waits
for its termination (e.g. /etc/rc). The runlevels field is
ignored.
- off
- This does nothing.
- ondemand
- A process marked with an ondemand runlevel will be executed
whenever the specified ondemand runlevel is called. However, no
runlevel change will occur (ondemand runlevels are `a', `b', and
`c').
- initdefault
- An initdefault entry specifies the runlevel which should be entered
after system boot. If none exists, init will ask for a runlevel on
the console. The process field is ignored.
- sysinit
- The process will be executed during system boot. It will be executed
before any boot or bootwait entries. The runlevels
field is ignored.
- powerwait
- The process will be executed when the power goes down. Init is usually
informed about this by a process talking to a UPS connected to the
computer. Init will wait for the process to finish before
continuing.
- powerfail
- As for powerwait, except that init does not wait for the
process's completion.
- powerokwait
- This process will be executed as soon as init is informed that the
power has been restored.
- powerfailnow
- This process will be executed when init is told that the battery of
the external UPS is almost empty and the power is failing (provided that
the external UPS and the monitoring process are able to detect this
condition).
- ctrlaltdel
- The process will be executed when init receives the SIGINT signal.
This means that someone on the system console has pressed the
CTRL-ALT-DEL key combination. Typically one wants to execute some
sort of shutdown either to get into single-user level or to reboot
the machine.
- kbrequest
- The process will be executed when init receives a signal from the
keyboard handler that a special key combination was pressed on the console
keyboard.
The documentation for this function is not complete yet; more
documentation can be found in the kbd-x.xx packages (most recent was
kbd-0.94 at the time of this writing). Basically you want to map some
keyboard combination to the "KeyboardSignal" action. For
example, to map Alt-Uparrow for this purpose use the following in your
keymaps file:
alt keycode 103 = KeyboardSignal
This is an example of a inittab which resembles the old Linux inittab:
# inittab for linux
id:1:initdefault:
rc::bootwait:/etc/rc
1:1:respawn:/etc/getty 9600 tty1
2:1:respawn:/etc/getty 9600 tty2
3:1:respawn:/etc/getty 9600 tty3
4:1:respawn:/etc/getty 9600 tty4
This inittab file executes /etc/rc during boot and starts gettys on
tty1-tty4.
A more elaborate inittab with different runlevels (see the
comments inside):
# Level to run in
id:2:initdefault:
# Boot-time system configuration/initialization script.
si::sysinit:/etc/init.d/rcS
# What to do in single-user mode.
~:S:wait:/sbin/sulogin
# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# What to do at the "3 finger salute".
ca::ctrlaltdel:/sbin/shutdown -t1 -h now
# Runlevel 2,3: getty on virtual consoles
# Runlevel 3: getty on terminal (ttyS0) and modem (ttyS1)
1:23:respawn:/sbin/getty tty1 VC linux
2:23:respawn:/sbin/getty tty2 VC linux
3:23:respawn:/sbin/getty tty3 VC linux
4:23:respawn:/sbin/getty tty4 VC linux
S0:3:respawn:/sbin/getty -L 9600 ttyS0 vt320
S1:3:respawn:/sbin/mgetty -x0 -D ttyS1
Init was written by Miquel van Smoorenburg (miquels@cistron.nl). This
manual page was written by Sebastian Lederer
(lederer@francium.informatik.uni-bonn.de) and modified by Michael Haardt
(u31b3hs@pool.informatik.rwth-aachen.de).