2003/12/11 kill

© November 2003 Tony Lawrence
One of the first things people using a Unix machine learn is how to kill processes. Unfortunately, they usually learn the wrong thing, and use "kill -9" indiscriminately.

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:

• A process can be sleeping in kernel code. Usually that's because of faulty hardware or a badly written driver- or maybe a little of both. A device that isn't set to the interrupt the driver thinks it is can cause this, for example- the driver is waiting for something its never going to get. The process doesn't ignore your signal- it just never gets it.
  
  
• A zombie process doesn't react to signals because it's not really a process at all- it's just what's left over after it died. What's supposed to happen is that its parent process was to issue a "wait()" to collect the information about its exit. If the parent doesn't (programming error or just bad programming), you get a zombie. The zombie will go away if its parent dies- it will be "adopted" by init which will do the wait()- so if you see one hanging about, check its parent; if it is init, it will be gone soon, if not the only recourse is to kill the parent..which you may or may not want to do.
  
  
• Finally, a process that is being traced (by a debugger, for example) won't react to the KILL either.
  
  

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.

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us