 |  |
| |
Sometimes it's necessary to eliminate a process entirely or to signal a process (Section 24.13); this is the purpose of the kill command. You can use the kill command with or without a signal id:
% kill pid % kill -signal pid
where pid is the process' identification number, and signal (which is optional) is the signal to send to the process. The default signal is number 15, the TERM signal, which tells the process to terminate. On some systems, the signal must be specified numerically; others allow you to use either the signal number or its symbolic name. [Use kill -l for a list of signal names; unfortunately, the listing doesn't show the correspondence of names and numbers. However, they are in order, so if you can count, you can figure it out. -- TOR]
Sometimes, a process may still exist after a kill command. If this happens, execute the kill command with the -KILL or -9 option. This almost always guarantees that the process will be destroyed. However, it does not allow the dying process to clean up, and therefore may leave the process' files in an inconsistent state.
Occasionally, processes will not die even after being sent the KILL signal. The vast majority of such processes fall into one of three categories:
Zombies. A process in the zombie state (Section 24.19) is displayed as Z status in BSD ps (Section 24.5) displays and as <defunct> under System V. When a process is exiting, it informs its parent of its imminent death; when it receives an acknowledgment, its PID is removed from the process table. A zombie process is one whose total resources have been freed, but whose parent process' acknowledgment has not occurred. Usually, init will step in when the parent is gone, but very occasionally this fails to happen. Zombies are always cleared the next time the system is booted and do not adversely affect system performance.
Processes waiting for unavailable NFS (Section 1.21) resources (for example, trying to write to a remote file on a system that has crashed) will not die if sent a KILL signal. Use the QUIT signal (3) or the INT (interrupt) signal (2) to kill such processes.
Processes waiting for a device to complete an operation before exiting. Often this means waiting for a tape to finish rewinding.
Killing a process may also kill all of its children. Child processes may not die if they're blocking or "catching" the signal you use -- although, as explained above, the KILL signal (9) will usually terminate those processes. Killing a shell can therefore kill all the foreground and stopped background processes initiated from that shell (including other shells). Killing a user's login shell is equivalent to logging the user out. This is a useful (if somewhat painful) way to recover from certain kinds of problems. For example, if a user manages to confuse his editor by mistyping control keys and escape sequences, or enters an infinite loop that he can't terminate by normal means, killing his shell will let him regain control of the situation, possibly at the cost of some work. Use the ps command to determine which process is the offending user's shell. Remember that you must be superuser (Section 1.18) to kill someone else's process.
If you're using the X Window System, Section 24.20 shows how to find which window has the processes you may need to kill.
--AF, from Essential System Adminstration (O'Reilly, 2002)
|  | |
| 24.11. Killing Foreground Jobs |  | 24.13. Printer Queue Watcher: A Restartable Daemon Shell Script |
Copyright © 2003 O'Reilly & Associates. All rights reserved.