Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

System call kill(pid, 0) returns SUCCESS for Zombie

93 views
Skip to first unread message

alex.v...@gmail.com

unread,
Nov 25, 2012, 3:35:07 AM11/25/12
to
Linux 2.6.32-279.5.2.el6.x86_64
HP-UX B.11.23 U ia64

System call kill(pis, 0) returns 0 (SUCCESS) for both alive and zombie processes.
Is there any system call to detect zombie process?

Kenny McCormack

unread,
Nov 25, 2012, 5:38:36 AM11/25/12
to
In article <19ee0fd4-a5c8-44bf...@googlegroups.com>,
system("ps -p {pid} -o state")

Should display a Z if it is a zombie.

--
People who say they'll vote for someone else because Obama couldn't solve
all of Bush's messes are like people complaining that he couldn't cure cancer,
so they'll go and vote for cancer.

Jorgen Grahn

unread,
Nov 25, 2012, 6:14:45 AM11/25/12
to
There surely is, since top(1) can tell you if a process is a zombie or
not. But what problem are you trying to solve? Something tells me
there may be a better way.

Two observations:
1 - AFAIK, all processes pass the zombie state as they die;
it's not an abnormal state
2 - you can see if a process is a zombie, but you cannot tell if its
parent is going to reap it a millisecond from now, on Thursday,
or never.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Barry Margolin

unread,
Nov 25, 2012, 7:27:47 AM11/25/12
to
In article <slrnkb3vd4.1...@frailea.sa.invalid>,
Jorgen Grahn <grahn...@snipabacken.se> wrote:

> On Sun, 2012-11-25, alex.v...@gmail.com wrote:
> > Linux 2.6.32-279.5.2.el6.x86_64
> > HP-UX B.11.23 U ia64
> >
> > System call kill(pis, 0) returns 0 (SUCCESS) for both alive and
> > zombie processes. Is there any system call to detect zombie process?
>
> There surely is, since top(1) can tell you if a process is a zombie or
> not. But what problem are you trying to solve? Something tells me
> there may be a better way.
>
> Two observations:
> 1 - AFAIK, all processes pass the zombie state as they die;
> it's not an abnormal state
> 2 - you can see if a process is a zombie, but you cannot tell if its
> parent is going to reap it a millisecond from now, on Thursday,
> or never.

If it's your own child, you may have a good idea whether you're about to
reap it.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Jorgen Grahn

unread,
Nov 25, 2012, 9:38:32 AM11/25/12
to
On Sun, 2012-11-25, Barry Margolin wrote:
> In article <slrnkb3vd4.1...@frailea.sa.invalid>,
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>
>> On Sun, 2012-11-25, alex.v...@gmail.com wrote:
>> > Linux 2.6.32-279.5.2.el6.x86_64
>> > HP-UX B.11.23 U ia64
>> >
>> > System call kill(pis, 0) returns 0 (SUCCESS) for both alive and
>> > zombie processes. Is there any system call to detect zombie process?
>>
>> There surely is, since top(1) can tell you if a process is a zombie or
>> not. But what problem are you trying to solve? Something tells me
>> there may be a better way.
>>
>> Two observations:
>> 1 - AFAIK, all processes pass the zombie state as they die;
>> it's not an abnormal state
>> 2 - you can see if a process is a zombie, but you cannot tell if its
>> parent is going to reap it a millisecond from now, on Thursday,
>> or never.
>
> If it's your own child, you may have a good idea whether you're about to
> reap it.

Yes, but if that's what he wants, shouldn't he simply waitpid(2) or
waitid(2) instead of asking the OS what would happen if he did?

Lew Pitcher

unread,
Nov 25, 2012, 9:45:54 AM11/25/12
to
On Sunday 25 November 2012 06:14, in comp.unix.programmer,
grahn...@snipabacken.se wrote:

> On Sun, 2012-11-25, alex.v...@gmail.com wrote:
>> Linux 2.6.32-279.5.2.el6.x86_64
>> HP-UX B.11.23 U ia64
>>
>> System call kill(pis, 0) returns 0 (SUCCESS) for both alive and
>> zombie processes. Is there any system call to detect zombie process?
>
> There surely is, since top(1) can tell you if a process is a zombie or
> not. But what problem are you trying to solve? Something tells me
> there may be a better way.
>
> Two observations:
> 1 - AFAIK, all processes pass the zombie state as they die;
> it's not an abnormal state

True, but (as I understand it) incomplete.

All terminating processes must have their termination state collected,
either by their parent process, or (if the parent process has already
terminated) by init. There can be a detectable time between process
termination and process status collection in which the terminated process
will show as "zombie". However, under normal circumstances, this wait time
is minimal to none.

Init reaps orphaned deceased processes quite frequently, so /those/
processes don't often show up in a process listing as "zombie".

OTOH, a parented deceased process must have it's status reaped by the
parent, and should the parent /not/ collect the status in a timely manner,
then the deceased process will persistantly show as "zombie".

So, the processes that show up in the process list as "zombie" are most
often the ones where the still-living parent hasn't collected the status in
a timely manner.

> 2 - you can see if a process is a zombie, but you cannot tell if its
> parent is going to reap it a millisecond from now, on Thursday,
> or never.

True, but you can make an educated guess that might be useful.

Zombie processes with a PPID of 0 will be collected quickly (assuming that
init isn't stuck)

Zombie processes with a PPID != 0 will be collected when the parent gets
around to it.

You can pretty much discount the PPID == 0 zombies, unless you suspect a
systemic init failure.

Just my opinion.
--
Lew Pitcher
"In Skills, We Trust"

Jorgen Grahn

unread,
Nov 25, 2012, 10:23:59 AM11/25/12
to
Also true. But my point was this: you cannot walk through the process
table and count every zombie as an application bug. If you look again
a second later and it's /still/ there, then maybe.

Is this relevant? We don't know until the OP gets back with more
background information. My personal suspicion is that his solution
is to fix (or stop running) the software which produces zombies.

>> 2 - you can see if a process is a zombie, but you cannot tell if its
>> parent is going to reap it a millisecond from now, on Thursday,
>> or never.
>
> True, but you can make an educated guess that might be useful.
>
> Zombie processes with a PPID of 0 will be collected quickly (assuming that
> init isn't stuck)
>
> Zombie processes with a PPID != 0 will be collected when the parent gets
> around to it.
>
> You can pretty much discount the PPID == 0 zombies, unless you suspect a
> systemic init failure.

So in other words, exactly what I said?

alex.v...@gmail.com

unread,
Nov 26, 2012, 3:57:54 AM11/26/12
to
On Sunday, November 25, 2012 12:38:36 PM UTC+2, Kenny McCormack wrote:
> In article <19ee0fd4-a5c8-44bf...@googlegroups.com>,
>
> <alex.v...@gmail.com> wrote:
>
> >Linux 2.6.32-279.5.2.el6.x86_64
>
> >HP-UX B.11.23 U ia64
>
> >
>
> >System call kill(pis, 0) returns 0 (SUCCESS) for both alive and zombie
>
> >processes.
>
> >Is there any system call to detect zombie process?
>
> >
>
>
>
> system("ps -p {pid} -o state")
>
>
>
> Should display a Z if it is a zombie.
>
I will use that with popen() instead of system().
Thanks

Geoff Clare

unread,
Nov 26, 2012, 8:45:48 AM11/26/12
to
Lew Pitcher wrote:

> Zombie processes with a PPID of 0 will be collected quickly (assuming that
> init isn't stuck)
>
> Zombie processes with a PPID != 0 will be collected when the parent gets
> around to it.
>
> You can pretty much discount the PPID == 0 zombies, unless you suspect a
> systemic init failure.

Init usually has process ID 1. (POSIX allows it to be greater than 1,
but does not allow it to be 0.)

--
Geoff Clare <net...@gclare.org.uk>

0 new messages