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