Shulou(Shulou.com)06/02 Report--

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-X1Christ 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 0l1:1:wait:/etc/rc.d/rc 1l2:2:wait:/etc/rc.d/rc 2l3:3:wait:/etc/rc.d/rc 3l4:4:wait:/etc/rc.d/rc 4l5:5:wait:/etc/rc.d/rc 5l6: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.dK01dnsmasq K36mysqld K89netplugd S15mdmonitorK02avahi-daemon K44rawdevices K89pand S25bluetoothK02avahi-dnsconfd K50netconsole K89rdisc S25pcscdK02haldaemon K50tux K91capi S26acpidK02NetworkManager K50vsftpd K95firstboot S26apmdK03rhnsd K69rpcsvcgssd K95kudzu S26hiddK05atd K72autofs K99readahead_later S50hplipK05conman K73ypbind S00microcode_ctl S55sshdK05saslauthd K74ipmi S02lvm2-monitor S56cupsK10dc_server K74nscd S04readahead_early S56xinetdK10psacct K75netfs S06cpuspeed S80postfixK10xfs K85mdmpd S08ip6tables S85gpmK12dc_client K85messagebus S08iptables S90crondK15httpd K85rpcgssd S08mcstrans S95anacronK20nfs K85rpcidmapd S09isdn S95jexecK24irda K86nfslock S10network S97yum-updatesdK25squid K87multipathd S11auditd S99localK30spamassassin K87portmap S12restorecond S99smartdK35dovecot K88wpa_supplicant S12syslogK35winbind 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-DELETEca::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 runlevels1:2345:respawn:/sbin/mingetty tty12:2345:respawn:/sbin/mingetty tty23:2345:respawn:/sbin/mingetty tty34:2345:respawn:/sbin/mingetty tty45:2345:respawn:/sbin/mingetty tty56: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 gettyroot 2818 10 Jan09 tty3 00:00:00 / sbin/mingetty tty3root 2819 10 Jan09 tty4 00:00:00 / sbin/mingetty tty4root 2821 10 Jan09 tty5 00:00:00 / sbin/mingetty tty5root 2823 10 Jan09 tty6 00:00:00 / sbin/mingetty tty6root 3092 10 Jan09 tty2 00:00:00 / sbin/mingetty tty2root 3224 10 Jan09 Tty1 00:00:00 / sbin/mingetty tty1jdoe 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 5x: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.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.