18

I just noticed some zombie processes on CentOS 6.8(Final), tried to kill them but they are still there:

[root@host user]# ps -ef | grep git
tomcat     746     1  0 Jul18 ?        00:00:00 git clone https://github.com/angular/bower-angular.git -b v1.3.20 --progress . --depth 1
tomcat     747   746  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>
root     20776 20669  0 09:03 pts/3    00:00:00 grep git
tomcat   29970     1  0 Jul18 ?        00:00:00 git clone https://github.com/components/jqueryui.git -b 1.12.0 --progress . --depth 1
tomcat   29971 29970  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>

[root@host user]# kill 746 747 29970 29971

[root@host user]# ps -ef | grep git
tomcat     746     1  0 Jul18 ?        00:00:00 git clone https://github.com/angular/bower-angular.git -b v1.3.20 --progress . --depth 1
tomcat     747   746  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>
root     21525 20669  0 09:26 pts/3    00:00:00 grep git
tomcat   29970     1  0 Jul18 ?        00:00:00 git clone https://github.com/components/jqueryui.git -b 1.12.0 --progress . --depth 1
tomcat   29971 29970  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>

As you can see they are running for two months, and too if they are not harmful I would get rid of them, any alternative way to kill a Zombie?

  • 1
    have you tried kill -9? – Ipor Sircer Sep 19 '16 at 7:35
  • 7
    Only 747 and 29971 are zombie processes. The others might be locked up but they're not dead yet. – roaima Sep 19 '16 at 9:28
  • Seems you have a bug in some code running on tomcat... – Boris the Spider Sep 19 '16 at 10:41
  • 6
    Zombies - what are they? – sds Sep 19 '16 at 16:49
8

As mentioned by Heemayl, you cannot actually kill a zombie. It's already [un]dead...

However, the problem you are facing looks like a problem with the git clone command. It gets stuck somehow. Probably times out or fails in some other way? It is often because of some I/O that a process gets stuck to the point where a SIGTERM and SIGINT won't work.

To kill it, in this case, you want to use the -9 command line option. This means send the SIGKILL signal. You can actually use -KILL too.

[root@host user]# kill -KILL 746 29970

To get a list of available signals, use the list command line option.

[root@host user]# kill -l

This shows you the numbers and names (and you'll see that #9 says SIGKILL.)

  • 1
    Actually kill -KILL was the only command able to close these processes, for this reason I'am going to accept @Alexis Wilke answer. But surely I will like to express my gratitude to the @heemayl quick, wise and very informative answer +1. Thanks to everyone – lese Sep 21 '16 at 10:02
39

You can't kill a Zombie (process), it is already dead. It is just waiting for its parent process to do wait(2) and collect its exit status. It won't take any resource on the system other than a process table entry.

You can send SIGCHLD to its parent to let it know that one of its children has terminated (i.e. request it to collect child's exit status). This signal can be ignored (which is the default):

kill -CHLD <PPID>

(Replace <PPID> with the actual PID of the parent.)

Or you can kill the parent process so that init (PID 1) will inherit the zombie process and reap it properly (it's one of init's main tasks to inherit any orphan and do wait(2) regularly). But killing the parent is not recommended. Generally, creation of zombie processes indicates programming issue/issues, and you should try to fix or report that instead.

  • 8
    You can send SIGCHLD to it's parent to let it know that one if it's children has terminated (i.e. request it to collect child's exit status), this signal can be ignored (default) The problem with that is that if a process ignores SIGCHLD, no zombie would be created. So if it's not ignoring SIGCHLD, and zombies aren't getting reaped, the process is either buggy or doesn't care about zombie children. Given the process in question is git clone ..., I'm betting it simply doesn't care about zombie children since it's a (hopefully) short-lived process that does its job and then exits. – Andrew Henle Sep 19 '16 at 10:43
  • 1
    @AndrewHenle: While that's mostly true, the default action (SIG_DFL) for SIGCHILD is also to ignore it, but in this case zombies most certainly are not automatically reaped. – R.. Sep 19 '16 at 16:36
  • @R While that's mostly true, the default action (SIG_DFL) for SIGCHILD is also to ignore it, but in this case zombies most certainly are not automatically reaped. I'm not sure what you're referring to. Are you referring to the processes not getting reaped in the question? I'm not seeing how sending SIGCHLD to a process that has its SIGCHLD handler set to SIG_IGN (either explicitly or by default) is going to cause that process to reap any zombies. – Andrew Henle Sep 19 '16 at 20:50
  • 1
    @AndrewHenle, sending a SIGCHLD may work this time. The last time it may have missed the signal or two children died at the same time and the code is not smart enough to handle both deaths simultaneously. – Alexis Wilke Sep 20 '16 at 0:58
  • It can't hurt, but I wouldn't put odds on it working. – Barmar Sep 22 '16 at 1:26
1

to look for zombie processes:

ps aux | grep -w Z | grep -v grep

ps -eo stat,ppid | grep -w Z

to kill zombie process, the parent IDs need to be killed ie PPID:

kill PPID1 PPID2

kill $(ps -eo stat,ppid|grep -w Z|awk '{print $2}'|tr "\n" " ")
0

When a parent process dies, all zombie process will get cleaned up. Don’t kill parent process just to clean up zombie process. It will come again when you re-run your program. Fix your program with properly calling “wait ()” or “waitpid ()” system call.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.