内容: /etc/inittab文件介绍。



man 5 inittab


The inittab file describes which processes are started at bootup and

during normal operation (e.g. /etc/init.d/boot, /etc/init.d/rc, get‐

tys…). 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:


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 cor‐

responding tty, e.g. 1 for tty1. Some ancient login accounting

programs might expect this, though I can’t think of any.

lists the runlevels for which the specified action should be


action describes which action should be taken.

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 length of this field is limited to 127 char‐


The runlevels field may contain multiple characters for different run‐

levels. For example, 123 specifies that the process should be started

in runlevels 1, 2, and 3. The runlevels for ondemand entries may con‐

tain 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


Valid actions for the action field are:

The process will be restarted whenever it terminates (e.g.


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

boot The process will be executed during system boot. The runlevels
field is ignored.

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.

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


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.

The process will be executed during system boot. It will be exe‐

cuted before any boot or bootwait entries. The runlevels field

is ignored.

The process will be executed when the power goes down. Init is

usually informed about this by a process talking to a UPS con‐

nected to the computer. Init will wait for the process to fin‐

ish before continuing.

As for powerwait, except that init does not wait for the

process’s completion.

This process will be executed as soon as init is informed that

the power has been restored.

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).

The process will be executed when init receives the SIGINT sig‐

nal. 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.

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 follow‐

ing in your keymaps file:

alt keycode 103 = KeyboardSignal


This is an example of a inittab which resembles the old Linux inittab:

# inittab for linux



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


A more elaborate inittab with different runlevels (see the comments


# Level to run in


# Boot-time system configuration/initialization script.


# What to do in single-user mode.


# /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