Terminating Misbehaving Processes

Let's say you notice the system running more slowly than you think it should; you use su to access root, fire up top, and look at the processes. Sure enough, you see something like what's shown in Listing 15.4.

Listing 15.4. Output of top Showing a Possible Runaway Process

last pid: 67469;  load averages:  8.32,  5.49,  2.47   up 53+01:04:22  20:34:42 90 processes:  1 running, 88 sleeping, 1 zombie CPU states:  93.2% user,  0.0% nice,  0.2% system,  0.8% interrupt, 5.8% idle Mem: 153M Active, 23M Inact, 60M Wired, 7252K Cache, 35M Buf, 5112K Free Swap: 500M Total, 44M Used, 456M Free, 8% Inuse   PID USERNAME      THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND 19460 frank           1   2    0 25908K  2816K poll   0 131:15 92.43% testprog 67468 root            1  28    0  2036K  1024K CPU0   0   0:00  0.20% top   245 root            1   2    0   868K   232K select 1 178:48  0.00% healthd 18427 root            1   2    0  7592K  5124K select 0  81:01  0.00% named

Aha! There's your culprit: testprog. It seems that frank is running some experimental program that's perhaps not written very well, and it's taking up almost all the CPU's available cycles. Sometimes such a "runaway" process results from an infinite loop (a piece of code that never reaches a point where it can terminate) or a memory leak (the program keeps trying to grab more memory, whether it needs it or not). Chances are, the process isn't going to exit by itself cleanly; meanwhile, it's becoming more difficult for other processes to execute and terminate. This testprog process has to go.

Killing Processes Within top

To get rid of testprog or other runaway processes, press the K key. This brings up the "kill" prompt within top; this prompt is an interface to the kill command (or at least a simplified version of it). At the prompt, enter the PID of the offending process (19460, in this case). Because you're running with root privileges, the process most likely will immediately terminate, and the system will breathe freely once more. Now, you're safe to track down what happened; you'll probably want to start by sending messages to Frank and letting him know what his program did, in case he wasn't aware of how it behaved. (If he did know, you might need to lay down the law to prevent him from causing problems in the future.)

There are times when the kill command within top doesn't work, though, or you may need finer control over what signals you're sending to the processes. top's kill function is fine for routine termination of well-behaved processes, but it's only a subset of the functionality of the command-line kill program, which you may need to use instead.

The Command-line kill Program and Its Options

Its name is slightly misleading: kill does a lot more than simply terminate processes. Its full charter is to be a signaling mechanism by which processes can give each other commands of a fairly wide variety. Any user can use kill against any of his processes, but root is the only user who can kill other users' processes.

The simplest and most common usage of kill is for the purpose of terminating a process:

# kill 12553

This, however, sends only a certain kind of signal to the process: the TERM signal. This is a universal "quit" message that all UNIX programs understand, but it isn't guaranteed to work. A number of other signals exist, too. Table 15.1 shows the more important ones.

Table 15.1. Commonly Used kill Signals

Signal	Symbolic Name	Meaning
1	HUP	Hang up (terminate and restart)
2	INT	Interrupt
3	QUIT	Quit
6	ABRT	Abort
9	KILL	Non-ignorable kill
14	ALRM	Alarm
15	TERM	Terminate cleanly

You can use any of these signals by specifying either the signal number or its symbol:

# kill -HUP 8112 # kill -9 966

The first command tells the process to shut itself down cleanly and restart itself with the same argumentsrereading any input files and taking on a new PID. This is useful when you've changed something in a program's config file and need to restart the process to incorporate the changes.

The second command, which should be used only in the direst need and when all other options have failed, sends a low-level "super-kill" signal that terminates the process at all costs, regardless of how stubborn the process is. (This function is equivalent to the "End Process" command in Windows.) This command makes the process quit in an unclean fashion and might leave files open or connections in an orphaned state. This command can be a lifesaver, but don't use it unless you absolutely have to (for instance, if the kill and kill -TERM commands have no effect). See http://sial.org/code/shell/tips/kill-9/ for a discussion of when kill -9 is and is not appropriate to use.

Note

The kill program is not infallible; there are some occasions when even a kill 9 will not terminate a process that has become completely unresponsive to signals. Some processes under certain circumstances can become "zombies," meaning that they never die and can't be killed. Most zombie processes just sit there and don't take up any significant system resources. However, if in some rare case you have a zombie process that is interfering with general system operation, a reboot may be the only way to clear it.

These signals are the only ones you're likely to use in everyday process control. The other signals are typically ignored by programs that aren't specifically written to respond to them.