What is a zombie process and how do I kill it?
Virtual Shotguns?
Solution 1:
Oh, god! No no no. Don't use kill -9.
It doesn't give the process a chance to cleanly:
shut down socket connections
clean up temp files
inform its children that it is going away
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.
Solution 2:
Zombie process (actually now they're called <defunct>) isn't really a process. It's only entry in the process table, so the parent process can do wait() syscall.
You shouldn't worry about them. They do not occupy any resources, they will disappear either when their parent calls wait() on when the parent itself dies.
Solution 3:
There is already an accepted answer, however: you CAN kill the zombie process. Attach with the debugger to the parent process and call waitpid function. E.g.: - let's assume that the parent has PID=100, the zombie process has PID=200
$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit
Solution 4:
It's a process that has been completely deallocated but still exists in the process table. Contrast this with an orphan process, whose parent has died but is still executing.
Here's some advice on getting rid of them.
Solution 5:
A zombie process has no resources allocated to it whatsoever, other than the entry in the process tree. This happens when a process completes, however the parent process has not yet reaped it, (i.e., waited on it).
You can try and force the parent to do this if you want by sending it a SIGCHLD (kill -20), to the parent, but there's no guarantee that the parent will honor it.
You'll often see them for short periods of time (for example while viewing the process tree using top) - this is normal; In the time slice between the time that a child process completes, and the parent polls for it - the child process will appear as a zombie.
If you see zombie processes that continually exist however - which is not normal - there is still no need to be concerned - again as there is not resource allocated to a dead process - it generally means that the application is poorly written by crappy developers.
The only time that you should be concerned from zombie processes, is when you see lots and lots of them, for example if the same crappy application mentioned above is placed under load.
We have alot of crappy developers where I work, and so I have the privilege of dealing with such issues and learning all sorts of useless stuff while doing so. In fact - my team often resorts to using the crappy shell scripts written by out crappy developers in interviews - if the candidate can pick that the script is indeed crapy, and tell us why it's crappy, he has a good foot in the door.