A better way to kill processes is to send a hangup (kill -1) or a sigterm (kill -15). Any process has the option of catching such signals and doing any final housekeeping tasks before dieing. The process can also choose to ignore you, so you may ultimately need a -9 anyway, but at least you gave it a chance to die gracefully.
The problem is that "-9" is an absolute kill - any process that is the target of that signal has to die immediately: no chance to clean up anything it might be doing, write out its file buffers or anything else: just die, right now. Unlike a "-15" or a "-1", the process itself never even knows this was done - it's the kernel that does the killing.
By the way, the "receives" doesn't happen in other cases, too. A process that is sleeping down in a driver doesn't get signals until the kernel wakes it up. That's why some processes seem unkillable:
But see TASK_KILLABLE, something new in Linux.
Kill isn't always about killing. Many processes uses signals ("signal" would have been a better name for "kill") to alert them to needed actions. "kill -1" often causes a process to re-read its configuration files, for example.
Many shells allow a "kill -0" to check if a process still exists. This can be useful where "wait" isn't what you want or where your shell didn't start the process you want to monitor. You can use that to kill off a process that might hang:
# spin off something that might hang: myprog & THAT=$! sleep 300 kill -0 $THAT && echo "still running"
Linux "killall" is a useful program. You can "killall httpd" to kill of all running httpd processes. But watch out: some systems (SCO) have a similarly named command that has much more drastic consequences: see SCO killall.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-03-20 Tony Lawrence
If debugging is the process of removing bugs, then programming must be the process of putting them in. (Edsger W. Dijkstra)