Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

(OS: Debian variant.)

Having a process with zombie-status. The PPid belonged to a gvim process. The contents of /proc/[pid]/wchan is do_exit, /comm is sh and /cmdline is empty, /status is shown below.

Could this be a bug in gvim? From the Wikipedia entry on Zombie process I read that a program can voluntarily reject to call wait but this was for a gvim session that had been idle for quite some time. I closed the gvim process – but the zombie still lurks around. Could this indicate a OS bug?

Again from Wikipedia:

If the parent program is no longer running, zombie processes typically indicate a bug in the operating system.

And how often does init reap forsaken processes? It has been at least 60 minutes since gvim's demise but it still there.

On the other hand could it be sh and not gvim?

The /status file states SigQ of zero.

$ less /proc/30339/status
Name     : sh
State    : Z (zombie)
Tgid     : 30339
Pid      : 30339
PPid     : 29673
TracerPid:     0
Uid      :  1000    1000    1000    1000
Gid      :  1000    1000    1000    1000
FDSize   :     0
Groups   :     4 7 20 24 27 29 30 46 107 124 127 1000 
Threads  :     1
SigQ     : 0/30658
SigPnd   : 0000000000000000
ShdPnd   : 0000000000000000
SigBlk   : 0000000000000000
SigIgn   : 0000000000003001
SigCgt   : 0000000000010002
CapInh   : 0000000000000000
CapPrm   : 0000000000000000
CapEff   : 0000000000000000
CapBnd   : ffffffffffffffff
Cpus_allowed     :   3
Cpus_allowed_list:   0-1
Mems_allowed     :   1
Mems_allowed_list:   0
voluntary_ctxt_switches   :   2
nonvoluntary_ctxt_switches:   3

Not that it destroys my beauty sleep, but wondering …

share|improve this question

5 Answers 5

up vote 2 down vote accepted

Seeing zombies tends to indicate a bug in the process that spawned them: that process is supposed to reap the zombies (by calling wait) or explicitly ignore SIGCLD (or set the SA_NOCLDWAIT flag).

However this is a minor bug. Zombie processes only consume an entry in the process table, which is a negligible amount of resources. The problem only becomes significant if a process leaves thousands of zombies behind.

You have not killed the parent process of the zombie: otherwise the zombie would have gone away. Process 29673 (the zombie's parent) is still alive and kicking (but not waiting). Either this is not Gvim but some subprocess of it, or you've closed a Gvim window but the program is still running. Run ps l 29673 to see what this process is.

share|improve this answer
    
Yes, you are absolutely correct. Problem somewhere between the user and the keyboard - as after ending Gvim by :q I searched for the PID but didn't find it. Must have typed wrong. (Very embarrassing). That process (29673) was a non Gvim process with no cmdline and 1 as PPID. Weirdest little thing. But; have learned quite a bit about zombies, what and why anyway, so not a complete loss :) –  Zimzalabim Apr 30 '13 at 10:32

Does this happen every time you use gvim? Does gvim works apart from leaving a zombie after it exits? Unless it causes real problems, I would simply ignore it - zombies doesn't tax the system's resources. I wouldn't be surprised if it was a bug in gvim - or perhaps in gtk, but unless the program doesn't work at all, I'd ignore it.

A zombie/defunct process typically happens when a child-process exits before the parent start listening to it. The child "sticks around" because there was no program around to receive it's exit-status, even though it did terminated satisfactory - hence it becomes a zombie. Another reason you get zombies, can be when a large process-tree comes tumbling down - perhaps because someone attempted to kill one or more processes in the tree.

A zombie is really a way for the OS to keep the exit-status and other information about a process that didn't terminate quite correctly around, in case anybody is interested. Apart from a entry in process-table, a zombie takes up no resources (ie. no memory or cpu).

IMHO WikiPedia is wrong - or at least easy to misunderstand - when it claims un-reaped zombies means an error with the OS if they linger after the main process it was spawned by exits. It's not unusual that a zombie survives it's parents, in which case it's adopted by init (PID 1). init may eventually reap it, but some zombies - even those adopted by init - may very well remain until reboot. As long as you don't have so many zombies that they fill-up the process-table, they're hardly any problem.

Of course, zombies do often signify something is wrong - that a program spawns a child which dies before the parent expects - but it doesn't have to be the OS which is the problem. It certainly may be OS-components which cause it though - eg. a missing or malconfigured sound-server, causes a child-processes supposed to handle sound for a program to exit immediately, thus sticking around as zombies.

share|improve this answer
    
No. It only happens sporadically. It is more a case of curiosity then an issue. As it is rather infrequent I find it hard to debug – by using gdb or the like. gvim also frequently pollutes the terminal with something like LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent. – But this only happens on exit. (or :q). The zombies appear while active or sleeping. –  Zimzalabim Apr 29 '13 at 9:50
1  
No, WP is correct: a zombie that remains for a non-negligible amount of time indicates an error somewhere. Not in the OS: in the parent of the zombie (or sometimes in the child itself, if it wasn't supposed to die so soon). If the parent dies, init will reap the zombie as soon as it sees it. –  Gilles Apr 30 '13 at 0:01

If you're continuously encountering a zombie process I would be inclined to think that there is definitely something wrong. Zombie process do occur. I generally see a few a month on the various systems that I maintain both at work and home.

Usually they can be accounted for due to operator error or to an issue with a particular piece of software. Reboots usually resolve them and they typically don't occur again for some time.

If they're troubling you, you can try and attach to their parent process ID (PPID) using gdb to see what's up or even attempt to kill them:

$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit

If you're up to it I'd read through these additional resources below for other techniques on attempting to deal with them.

References

share|improve this answer
    
Do you mean attach to parent PID? As a zombie only reside as part of process table in kernel. It has no /mem or other resources – so a gdb is futile. (If I understand it correctly). –  Zimzalabim Apr 29 '13 at 9:33
1  
Sorry that should've ready PPID, not just PID. You can refer to this URL, they show an example where they're connecting to the PPID: stupefydeveloper.blogspot.com/2008/12/linux-zombies.html –  slm Apr 29 '13 at 12:52

As ever - it depends. Most monitoring-tools will turn yellow or red of they encounter more than a certain number of zombie processes.

So basically - yes - it is normally a sign of a problem.

But I have seen programs that spawn zombie-processes as part of their "normal" operations. These zombie-processes went away when the according top-level-api (I do not say parent process here) was called with the "quit/exit" command.

So in these cases it seems that the application took care (and perhaps needed) these zombies. So for monitoring I had to define an exception on the servers where these applications were running.

In other cases zombies went away after a short time - so you can have certain non-persistent-system states with zombie-processes.

In your case: If gvim is done there should be no zombie left - so propably a bug.

share|improve this answer

In Unix/Linux, new processes are created by the fork(2) system call (or some sugared-over version of it, or perhaps by another variant of clone(2)). It is the parent's responsibility to do a variant of wait(2) to collect the exit status of the child process (if the parent finishes before the child, init(8) gets to take care of the orphan). A terminated process whose exit status hasn't been collected is a zombie. Zombies are a sign of irresponsible parenthood.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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