51

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
gagneet
  • 35,729
  • 29
  • 78
  • 113
  • The fact that the parent process id is 1 means that whatever started it is dead. I'm not sure why "init" hasn't reaped it yet. – Paul Tomblin Dec 10 '08 at 16:46
  • That's a zombie! Don't worry, he's not harmful and doesn't consume anything. – Loki Dec 10 '08 at 17:49
  • 3
    Just saw that on reddit: http://www.cs.cornell.edu/Courses/cs414/2007sp/tanenbaum.jpg – Loki Dec 10 '08 at 17:51
  • On solaris there is **preap** that reap zombie processes, unfortunately not children of init. – Kjell Andreassen Aug 30 '11 at 12:02
  • Loki - zombie processes can create problems if they appear in large numbers. The root cause of the zombie process if of great concern. – benc Jun 15 '13 at 19:52
  • @Loki DO WORRY! in my case this totally blocks me from restarting my program. I need to restart my computer to be able to do it.. – Mehdi Apr 21 '16 at 12:03
  • How is this off topic? LOL. Anyway see https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work – rogerdpack Apr 30 '19 at 15:15

5 Answers5

42

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.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • 3
    Init certainly reaps dead children. Think about the implications of that not being true: Every child process would have to terminate before its parent. – janm Mar 10 '09 at 12:14
  • 1
    Restarting init may help - on Linux, telinit u should be able to do that. – bdonlan Jun 15 '09 at 01:21
  • 7
    That last sentence is completely wrong. Reaping children is pretty much the *only* thing that init does! – William Pursell Feb 10 '12 at 18:44
  • @WilliamPursell, thanks, I have edited the last sentence. Init does reap child processes, but clearly sometimes it can't get rid of zombies. – Bill Karwin Jan 29 '13 at 17:20
24

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

curtisk
  • 19,950
  • 4
  • 55
  • 71
7

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.

janm
  • 17,976
  • 1
  • 43
  • 61
  • 1
    "If kill -9 fails to kill a process the cause is almost always a driver or operating system bug." This is true, except for a defunct process. kill -9 is not going to do anything to a defunct process, only sends sends SIGKILL to the kernel about the process, but the kernel does not manage the process table on the basis of this signal. – benc Jun 15 '13 at 20:02
  • @benc: I agree, a zombie process is already dead and will not die any more in response to SIGKILL. However, the rest of my answer stands: There appears to be a bug causing this process to not be reaped by init when it calls wait(). – janm Jun 17 '13 at 06:59
0

The process probably hangs in e.g. ignoring signals like SIGPIPE, check with strace -p <pid> what is happening here.

Charles Menguy
  • 40,830
  • 17
  • 95
  • 117
tolazy
  • 9
  • 1
0

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. :)

Brian Knoblauch
  • 20,639
  • 15
  • 57
  • 92