Processes Running from inittab

215
■ ■ ■
CHAPTER 33
Processes Running from inittab
I
n several chapters of this book,
1
I discuss system monitors and some methods of run-
ning them on your machine at all times. By automatically starting a process at the system
level you can accomplish this task in multiple ways without user interaction. There is
cron, the system scheduler, as well as at, another scheduling utility. You also can start a
process with an rc (run control) startup script, traditionally located in the /etc/rc direc-
tory, which is processed automatically at boot time.
Here I want to discuss the init process. The init man page states that it is “the parent
of all processes.” Init runs the scripts that, in turn, run the startup scripts living in the
/etc/rc directories.
2
It also controls the running system’s runlevel. Init is started as the
last step in the system boot process. If you are looking for the init configuration parame-
ters, they are kept in the /etc/inittab file.
The main problem with monitors that need to run on the system permanently is that
if they die or have to be killed, it is challenging to get them restarted automatically. The
methods for automatically starting processes have some limitations on their ability to
keep processes running.
System-startup scripts will start a process, but have no notification or recovery method
that can be used if a process ends. In addition, these scripts are run only at boot time, and
many systems run continuously for long periods between reboots.
Cron and at jobs that start processes can be scheduled to run frequently, but the pro-
cess code would need to be written so that it recognizes if another instance of itself is
already running. As you’ll see, scheduled tasks are not a terribly efficient use of system
resources. Although a process may run for long periods of time without issues, the

scheduler also uses some resources to continuously check and/or start the process.
Additionally, if a process does die or get killed, there is a period of time before the next
scheduled job when the monitor is not running.
1. Log-file monitoring is covered in Chapter 7, process monitoring in Chapter 31, file-count monitoring
in Chapter 32, and network monitoring in Chapter 42.
2. The startup scripts may be found in different locations depending on your operating system. /sbin/
rc#, /etc/init.d/rc#, and /etc/rc# are some of the locations I have seen.
216
CHAPTER 33
■
PROCESSES RUNNING FROM INITTAB
This is where init comes in. There is an action value among the /etc/inittab entries
called respawn that is quite useful for certain tasks. When an entry is added to the
inittab and the action defined for that entry is respawn, init makes sure that a process
corresponding to that entry is always running. If the process dies or is killed, init will
automatically restart or “respawn” it. The process restart is nearly instantaneous, and
the amount of time during which no instance of the desired process is running is negli-
gible. The following are a few example lines from a system inittab file:
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
An /etc/inittab entry takes the form of a line with four colon-separated fields. The
first field is a unique identifier for the entry, of one to four characters in length. The sec-
ond field is a list of the runlevels in which the entry should be run. In these examples, each
of the entries will be run in runlevels 2 through 5. The third field names the action to be
taken, which in this case is respawn. (init can perform a number of actions besides
respawn on a process, such as once, off, boot, and wait.) The last field is the script or

program that you want to run.
Respawn entries are likely to be part of the default /etc/inittab file for starting the
boot-time rc scripts or getty login sessions, as seen in the preceding sample entries.
I have also used init in this way to make sure monitors that are critical to tracking
system health are always running. The init process is the top dog of all processes on a
running system; if it can’t keep processes running, your system is probably fairly “sick”
and you are likely to have bigger problems than deficient monitors.
The following is an example of an entry I have used for my system monitors in the /etc/
inittab. The im identifier is arbitrary and needs only to be unique in the file as a whole.
It simply identifies the entry in the file. The process is run on runlevels 3 and 5 and is
respawned if it dies. It executes the MyMonitors script.
im:35:respawn:/bin/nice /usr/local/bin/MyMonitors >/dev/null 2>&1
Entries can be added to the /etc/inittab file at any time, but init won’t automatically
reread the inittab file when it is modified. You can manually cause such a rereading by
issuing the init q command as root, which will reread the file and implement the current
configuration.
One potential issue to watch for if you create a respawn inittab entry is that the script
to be called should include code enabling it to run continuously. If you create a script that
performs a monitor function and exits when finished, init will assume the program is
constantly dying and continuously try to restart the process. On most systems, if this hap-
pens you will start receiving messages in the system logs warning you that the process is
CHAPTER 33
■
PROCESSES RUNNING FROM INITTAB
217
“respawning too fast.” Init will then disable the respawn of the job for a period of time
since it recognizes that there is some type of issue with the configured entry. The issue
could be that the configured job runs and exits normally whereas respawned jobs should
run continuously, or simply that the syntax of the inittab line is incorrect.