Basic Use of kill

Technically, kill is a tool that sends signals to processes. These signals may or may not cause the signaled processes to terminate. You can obtain a list of signals (both their numbers and their names) by typing kill -I. Table 14.3 summarizes the signals you're most likely to send via kill.

Note Some shells, including bash andcsh, include built-in implementations ofkill. As with nice, you can bypass the built-inkill provided by these shells by typing the complete path to the kill binary, usually/bin/kill.

Table 14.3: Common Signals

Signal Number


Signal Effect




Hang up—indicates that the terminal a process is

using has closed. Daemons that don't run in a

terminal often respond to this signal by rereading

configuration files or restarting their logging tools.

Signal Number

Signal Name

Signal Effect



Interrupt—end program operation. The kernel sends this signal when you press Ctrl+C.



Quit—terminate and leave a core file for debugging purposes. Normally initiated by a user action.



Abort—terminate and leave a core file for debugging purposes. Normally initiated by a debugging process or self-detected error.



Kill—end program operation ungracefully; the program may not save open files, etc.



User signal 1—Effect varies from one program to another.



User signal 2—Effect varies from one program to another.



Terminate—end program operation gracefully (closing open files, etc.).



Continue—resume processing; undo the effect of a SIGSTOP signal.



Stop—suspend program operation, similar (but not identical) to the effect of pressing Ctrl+Z.

The syntax for kill is shown here: kill [-s signal] pid[...]

The syntax for kill is shown here: kill [-s signal] pid[...]

You can pass the signal by name or by number; for instance, kill -s 9 6940 and kill -s SIGKILL 6940 are equivalent. You can also usually omit the -s and add a dash to the signal name or number, as in kill -SIGKILL 6940. When you pass a signal name, the inclusion of the SIG portion is optional; for instance, KILL and SIGKILL are equivalent. (In practice, you may need to omit the SIG portion sometimes.) If you don't pass any signal specification, kill uses SIGTERM. Likewise, not all processes respond to all signals. If a process fails to respond to a signal, it will instead terminate, as if it had been passed a SIGTERM signal.

If a process is out of control (say, it's become unresponsive and is consuming excessive CPU time), you can try killing it. It's usually best to try SIGTERM first, which is the default, so typing kill pid is the usual first step. Programs that are out of control, though, frequently don't respond to this polite request to shut down, so you may need to take a firmer hand. You can do this by passing SIGKILL, which a process can't ignore. Only root or the owner of a process may terminate it.

One problem with kill is that you need a PID number. You can find a PID for a process by using ps, top, or a similar utility. If you know that the crunch process is out of control, for instance, you can type a command such as ps -C crunch to locate crunch's PID. Some daemons also store their PIDs in files, usually for the benefit of SysV startup scripts. These files typically reside in /var/run and are named after the process to which they refer, with names ending in .pid. For instance, /var/run/ holds the PID for crond. Unfortunately, sometimes a given program is running many times on a single computer, so isolating the instance you want to kill can be tricky. You may be able to use the user ID, as reported by many ps options, to help narrow the field. If the program is consuming inordinate amounts of CPU time, it may float to the top of the display in top.

If you're certain that only one instance of a program is running and if you know the process name, you can use killall instead of kill. This program works much like kill, but you pass it a program name instead of a PID, and killall kills all running instances of the specified program. For instance, killall crunch kills all processes called crunch.

Warning Some Unix-like OSs provide a program called killall that kills all running processes. Thus, you should not use killall on an unfamiliar system until you've checked the local system's documentation to be sure that killall does what you expect it to do.

0 0

Post a comment