Unix How To: The Linux /etc/inittab file

One of the files that the average Unix sysadmin rarely looks at, almost never changes and yet depends on every time he or she reboots a system is the /etc/inittab file. This modest little file controls what happens whenever a system is rebooted or forced to change run levels. Let's take a look at the configuration lines that tell your system what it's supposed to do when you hit that power button.

NOTE: The /etc/inittab files on Solaris and other Unix systems that share this way of booting follow the same general rules and most of what is described below applies equally well to those Unix variants.

To begin with, the /etc/inittab file usually starts out with a block of comments describing the content of the file or giving credit like the lines shown below.

#
# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
#
# Author:       Miquel van Smoorenburg, 
#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

Your /etc/inittab file might contain descriptions of the different run states that the system can assume. For those of you unfamiliar with this concept, a run state is basically a way to describe what is running on the system when that state is achieved. For example, run state 3 is "full multiuser mode" for most Unix systems and will have users logging in and all the expected system services running to support their use of the system.

Here's a sample of this section of the /etc/inittab file. Notice how it defines each run level for the sysadmin.

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#

One of the most critical lines in the /etc/inittab file is the one that defines the default run level -- that is the run level that will be assumed whenever you boot the system without specifying an alternate boot level. For most Unix systems, the default run state is 3 as shown below.

id:3:initdefault:

Since this "initdefault" line contains "3" as the second field, run state 3 is the default.

Another important line on Linux systems is the sysinit line shown below. This tells the system to run the /etc/rc.d/rc.sysinit script when the system is booted.

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

Once the system has run rc.sysinit and knows the run state that it is expected to achieve on bootup, it will select the appropriate line from the list below and run the /etc/rc.d/rc script with the argument appropriate to the run level specified.

Normally, this will be "rc 3", the fourth line in the list below.

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

As you have likely surmised, the system scans the second column for the one that corresponds to the run level being requested by the initdefault setting or the controlling user's init command.

The /etc/rc.d/rc script will then use the specified run level to determine which set of run scripts to execute. Under normal conditions, then, rc will run with "3" as its argument and will run all the scripts in the /etc/rc3.d directory. It will run the kill scripts (those that start with an uppercase "K") first and then the start scripts (those that start with an uppercase "S") using lines like this:

for i in /etc/rc$runlevel.d/K* ; do

If you look at the contents on the /etc/rc3.d directory on a Linux system, you will see something like this -- a large collection of both kill and start scripts that determine what is shut down (if running) and what is started.

$ ls /etc/rc2.d
K01dnsmasq         K36mysqld          K89netplugd         S15mdmonitor
K02avahi-daemon    K44rawdevices      K89pand             S25bluetooth
K02avahi-dnsconfd  K50netconsole      K89rdisc            S25pcscd
K02haldaemon       K50tux             K91capi             S26acpid
K02NetworkManager  K50vsftpd          K95firstboot        S26apmd
K03rhnsd           K69rpcsvcgssd      K95kudzu            S26hidd
K05atd             K72autofs          K99readahead_later  S50hplip
K05conman          K73ypbind          S00microcode_ctl    S55sshd
K05saslauthd       K74ipmi            S02lvm2-monitor     S56cups
K10dc_server       K74nscd            S04readahead_early  S56xinetd
K10psacct          K75netfs           S06cpuspeed         S80postfix
K10xfs             K85mdmpd           S08ip6tables        S85gpm
K12dc_client       K85messagebus      S08iptables         S90crond
K15httpd           K85rpcgssd         S08mcstrans         S95anacron
K20nfs             K85rpcidmapd       S09isdn             S95jexec
K24irda            K86nfslock         S10network          S97yum-updatesd
K25squid           K87multipathd      S11auditd           S99local
K30spamassassin    K87portmap         S12restorecond      S99smartd
K35dovecot         K88wpa_supplicant  S12syslog
K35winbind         K89dund            S13irqbalance

The following line will be unfamiliar to Solaris sysadmins, but the "control alt delete" sequence will be recognized by just about anyone who has worked with Windows systems

Here we have this particular key sequence signalling a shutdown operation.

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

A shutdown operation will also be initiated if a powerfail condition is recognized, as shown and explained in the lines below.

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

The following series of lines use the "respawn" option to keep six mingetty processes running on the system. If someone tries to kill one of these processes as root, the process will simply be respawned. Only critical processes are set up in this way to keep them safe from anything else happening on the system.

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

If you're curious about these processes, check them out on the running system and you'll see
something like this:

$ ps -ef | grep getty
root      2818     1  0 Jan09 tty3     00:00:00 /sbin/mingetty tty3
root      2819     1  0 Jan09 tty4     00:00:00 /sbin/mingetty tty4
root      2821     1  0 Jan09 tty5     00:00:00 /sbin/mingetty tty5
root      2823     1  0 Jan09 tty6     00:00:00 /sbin/mingetty tty6
root      3092     1  0 Jan09 tty2     00:00:00 /sbin/mingetty tty2
root      3224     1  0 Jan09 tty1     00:00:00 /sbin/mingetty tty1
jdoe      4877  4684  0 20:33 pts/11   00:00:00 grep getty

Here's another "respawn" line that you might see in your /etc/inittab line. This line keeps the xdm (X display manager) up and running in run state 5.

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

From this line and the comment near the top of the file, you can see that run state 5 -- at least on this particular Linux system -- represents multi-user mode with X11 running.

Most Linux sysadmins know how to properly add both kill and start scripts to the appropriate /etc/rc?.d directory to ensure that services are started in the appropriate run state, but they might not know exactly why adding a script to /etc/rc3.d or /etc/rc2.d has the effect that they want. A little time spent with the /etc/inittab file will likely answer any questions they might have on how this process works.