Unix How To: The Linux /etc/inittab file

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 K15 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 seesomething 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.

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。