Very interesting discussion

I was searching for a decent way to kill hung jobs and stumbled onto following discussion: Orig URL: http://superuser.com/questions/49024/kill-9-programs-but-they-still-hang-on It's very informative! --------------------------- A: I tried to kill all my background jobs submit earlier under KUbuntu by kill -9 $(jobs -p) Although this command immediately gave the message like [1] Killed myjob1 [2] Killed myjob2 I can still see their processes hanging in the output of top and the CPU and memory usages are not changed in the output of uptime and free. So I guess I must have not killed them properly. Can someone please explain what's happening to me and what shall I do? I found that in top, if type k and input the PID I can kill the processes one by one. SO is this different from the command kill? I also found somewhere online http://www.ruhr.de/home/smallo/award.html about not recommending kill -9 Useless Use of Kill -9 form letter (Quote abomination) No no no. Don't use kill -9. It doesn't give the process a chance to cleanly: 1) shut down socket connections 2) clean up temp files 3) inform its children that it is going away 4) reset its terminal characteristics and so on and so on and so on. Generally, send 15, and wait a second or two, and if that doesn't work, send 2, and if that doesn't work, send 1. If that doesn't, REMOVE THE BINARY because the program is badly behaved! Don't use kill -9. Don't bring out the combine harvester just to tidy up the flower pot. Is this true? What does it mean by "send 15", "send 2" and "send 1"? Are they commands themselves or "kill -15 PID", "kill -2 PID" and "kill -1 PID"? Thanks and regards!

5 Answers

Your process is probably dead but it still show up in the process table entry because it is a "zombie process". When a child process terminated and completely disappeared (except its process table entry) and the parent wouldnt be able to fetch its termination status (thru any of the wait functions), it is called zombie... Killing (thru signal) a zombie wont work because it is already terminated. What you need to do is find out its parent process and kill thjat one cleany, thus not using kill - 9 here are two simple steps to kill a zombie... if the parent is still alive, try to kill it (or SIGHUP is all you need) if number 1 fails, there is a bug in the kernel.... reboot is your friend and fix that bug :->

see man kill for a definition of the various signals available, but yes. 15 is SIGTERM, and asks a program to exit. 2 is SIGINT and is equivalent to Control-C 1 is SIGHUP, and indicates that the terminal has hung up. These inform a process that the user is "done" with the process, though they indicate somewhat different reasons.SIGTERM might be interpreted as "finish the currrent task, but then exit; don't start another", SIGINT means "abandon what you're doing and quit", SIGHUP just means nobody's listening anymore (a server process might legitimately react to SIGHUP by discontinouing its console output and continuing to run). 9 is SIGKILL, and is special in that it's the only one that the process can't catch and handle internally. It simply results in the kernel never returning control the the process, giving it no chance to clean up.

	It does mean using kill -15 PID (or another number) instead of kill -9 PID. The numbers are equivalent to different unix signals.

	It means type "kill -1" or "kill -15" instead of typing "kill -9". Kill -9 is a hardcore bullet in the head of any running process, kills it dead in a dirty state which can cause memory leaking, blah blah. If you're typing kill -9 and it's not working, then I'd look to make sure the process is not getting respawned, and that you have permission to kill that process.

Signal 9 is SIGKILL. Sending a SIGKILL is asking the OS to immediately kill the process, no questions asked. The process is not notified in advance and has no chance to clean up after itself. Signal 15 is SIGTERM. Sending a SIGTERM is asking the OS to ask the process to shut itself down. SIGKILL may be ignored if the OS thinks the process is doing IO, or if it's a Zombie (A child process whose parent didn't clean up after it). SIGTERM may be ignored by the application, but it is not recommended that applications do this, as OSes send SIGTERM during shutdown, followed shortly by SIGKILL if a program is still running. Note: The command line kill is always asking the OS to send a signal to the application, which it may or may not do based on who owns the process, etc... ---------------------- Ultimately I have decided to create a shell block for safely killing any process but it's going to be a big task. Below is what I am working on right now. killall myprocess MYPROCCOUNT=`ps -e | grep myprocess | wc -l` while [ $MYPROCCOUNT -gt 0 ]; do        MYPROC=`ps -e| grep myprocess| tail -1| xargs |cut -d" " -f1`        echo "MY_PROC_COUNT=$MYPROCCOUNT"        if [ -z $MYPROC ]; then            echo "All myproc's killed!"        else             echo "Killing $MYPROC"             `kill -9 $MYPROC`        fi        MYPROCCOUNT=`ps -e | grep myprocess | wc -l`        done --------------------------------------- I'll have to add lot more code to handle 15, 2 and 1 signals and then give 9 as ultimate kill!