Killing a defunct process on UNIX system
UnixProcessKillZombie ProcessUnix Problem Overview
I have a defunct process on my system:
abc 22093 19508 0 23:29 pts/4 00:00:00 grep ProcA
abc 31756 1 0 Dec08 ? 00:00:00 [ProcA_my_collect] <defunct>
How can I kill the above process, without a reboot of the machine? I have tried with
kill -9 31756
sudo kill -9 31756
Unix Solutions
Solution 1 - Unix
You have killed the process, but a dead process doesn't disappear from the process table until its parent process performs a task called "reaping" (essentially calling wait(3) for that process to read its exit status). Dead processes that haven't been reaped are called "zombie processes."
The parent process id you see for 31756 is process id 1, which always belongs to init. That process should reap its zombie processes periodically, but if it can't, they will remain zombies in the process table until you reboot.
Solution 2 - Unix
Did you check for a child process that may need to be killed first? Sometimes the jam up is down the line...
Try ps -ef --forest
to see what may be below it (if anything) then kill that first, then the one you already know about
Solution 3 - Unix
If kill -9 fails to kill a process the cause is almost always a driver or operating system bug.
The init process has adopted the process, but it cannot reap it. That is to say: when init calls wait(2) that process is not returned. One of the primary purposes of init is to reap dead orphaned children, so the problem is not that its parent died before it was reaped. Think: Otherwise, who reaps the results of a nohup'd process after logout?
Killing children of the defunct process is unlikely to help unless they are somehow related to the particular bug you are seeing.
Solution 4 - Unix
You're probably not going to be able to if killing the parent doesn't resolve it. For whatever reason the systems isn't collecting that zombie process.
FWIW, I've seen it quite a bit on the SCO Openserver boxen that I used to administer. Heavy multi-user usage and low system resources, but it didn't seem to hurt anything. Just annoyed me. :)
Solution 5 - Unix
The process probably hangs in e.g. ignoring signals like SIGPIPE, check with strace -p <pid> what is happening here.