C.4 The kill Command

You can use the kill command to stop or merely pause the execution of a process. You might want to kill a "runaway" process that is consuming CPU and memory for no apparent reason; you might also want to kill the processes belonging to an intruder. kill works by sending a signal to a process. Particularly useful signals are described in detail below. The syntax of the kill command is:

kill [-signal] process-IDs 

The kill command allows signals to be specified by their names in most modern versions of UNIX. To send a hangup to process #1, for example, type:

# kill -HUP 1

With some older versions of UNIX, you must specify the signal by number:

# kill -1 1

The superuser can kill any process; other users can kill only their own processes. You can kill many processes at a time by listing all of their PIDS on the command line:

# kill -HUP 1023 3421 3221

By default, kill sends signal 15 (SIGTERM), the process-terminate signal. Berkeley-derived systems also have some additional options to the kill command:

• If you specify 0 as the PID, the signal is sent to all the processes in your process group.

• If you specify -1 as a PID and you are not the superuser, the signal is sent to all processes having the same UID as you.

• If you specify -1 as a PID and you are the superuser, the signal is sent to all processes except system processes, process #1, and yourself.

• If you specify any other negative value, the signal is sent to all processes in the process group numbered the same as the absolute value of your argument.

To send any signal, you must have the same real or effective UID as the target processes or you must be operating as the superuser.

Many signals, including SIGTERM, can be caught by programs. With a caught signal, a programmer has three choices of action:

• Ignore it.

• Perform the default action.

• Execute a program-specified function.

There are two signals that cannot be caught: signal 9 ( SIGKILL) and signal 17 ( SIGSTOP).

One signal that is very often sent is signal 1 ( SIGHUP), which simulates a hangup on a modem. Standard practice when killing a process is to first send signal 1 (hangup); if the process does not terminate, then send it signal 15 (software terminate), and finally signal 9 (sure kill).

Sometimes simply killing a rogue process is the wrong thing to do: you can learn more about a process by stopping it and examining it with some of UNIX's debugging tools than by "blowing it out of the water." Sending a process a SIGSTOP will stop the process but will not destroy the process's memory image.

Under most modern versions of UNIX, you can use the gcore program to generate a core file of a running process, which you can then leisurely examine with adb (a debugger), dbx (another debugger), or gdb (yet another debugger). If you simply want to get an idea of what the process was doing, you can run strings (a program that finds printable strings in a binary file) over the core image to see what files it was referencing.

A core file is a specially formatted image of the memory being used by the process at the time the signal was caught. By examining the core file, you can see what routines were being executed, register values, and more. You can also fill your disk with a core file - be sure to look at the memory size of a process via the ps command before you try to get its core image!

NOTE: Some versions of UNIX name core files core.####, where #### is the PID of the process that generated the core file, or name.core, where name is the name of the program's executable.

Programs that you run may also dump core if they receive one of the signals that causes a core dump. On systems without a gcore program, you can send a SIGEMT or SIGSYS signal to cause the program to dump core. That method will work only if the process is currently in a directory where it can write, if it has not redefined the action to take on receiving the signal, and if the core will not be larger than the core file limits imposed for the process's UID. If you use this approach, you will also be faced with the problem of finding where the process left the core file!