zombie process

[Shivkumar]

Hi,

I observed a defuct (zombie) process.
$ ps -ef|grep defunct
root 27565 27437 234 Jun 14 ttypa 31788:23
sksonkar 26774 26050 0 21:42:59 ttyp7 0:00 grep defunct

How to find out which application or program caused this zombie process ?

Is there a way to kill this process ?

Thanks,
Shiv

[A. Clay Stephenson]

At this point, the only resource the process is consuming is a slot in the kernel's process table. You have one clue and that is the PPID (parent PID) so you might try a ps -p 27437 -f to see if this parent process still exists.

[Victor Fridyev]

Hi,

It does not look like a zombie, I hope you can kill it.
In order to see its parent look at PID=27437 and its parents.

HTH

[Arunvijai_4]

Hi Shiv,

You have the PPID, its easy to find the root cause. Use, # ps -p

-Arun

[Shivkumar]

Here is the output:

$ ps -p 27437 -f
UID PID PPID C STIME TTY TIME COMMAND
root 27437 27402 0 Jun 14 ttypa 0:00 ksh
$

Is there any clue with this output ?

Thanks,
Shiv

[Victor Fridyev]

Hi,

I'd like to see parents of PID=27402, but it looks like you have a login session on /dev/ttypa and the defunct process has been ran from it.
Did you try to kill it from the parent session ? What about kill -9 ?



HTH

[A. Clay Stephenson]

Try to kill the parent process. It's a bit unusual having a shell session open for nearly a month. I suspect all that killing the parent is going to do is change the PPID of the parent to 1 (init).

[Shivkumar]

I tried to kill parent process but is not getting killed. Also its ppid did not get converted to 1. BTW, i heard zombie process is a process whose parent dies before the child. But i am not able to understand how the parent process is alive in this case ?

Thanks,
Shiv

[Patrick Wallek]

It is possible that this process (27565) was started by ANOTHER process whose parent was the '-ksh' process. Thus, when the original parent of this process died, it inherited the '-ksh' process as its parent.

[Shivkumar]

Appreciate more thoughts of HPUX gurus :-))

best regards,
Shiv

[Steven E. Protter]

Shalom,

Zombies hold resources such as memory but don't consume new resources.

So long as there are not a lot of new zombies being created, your system can remain stable with a zombie process. Sometimes a zombie may have a critical file handle or somemthing on hold leaving you no choice but to deal with it.

There comes a point in every zombie's life where it must die. That is usually accomplished with a system boot.

SEP

[Arunvijai_4]

Hi Shiv,

Go through this link, it should help you http://en.wikipedia.org/wiki/Zombie_process

-Arun

[Victor BERRIDGE]

Hi Shiv,
To kill this type, you would have to do a kill -9 of PID AND PPID at once...
It is not (yet?) a true zombie (where PPID is 1...) so you stand a chance of killing it, what srupises me here is the fact that is has still a tty attached (ttypa)... where true zombie would be marked "?" I believe like Victor F. that you would have to trace PPIDs, it was mabe partt of a sequence of processes...


All the best
Victor

[A. Clay Stephenson]

Actually zombie processes consume no resources such as memory; they only occupy a slot in the kernel's process table and the only real impact would occur if the process table were so full that the system could no longer fork() to spawn new processes.

[James R. Ferguson · Accepted solution]

Hi Shiv:

It might be easier to see the ancestry of this process thusly:

# UNIX95= ps -efH -o pid,ppid,state,tty,args|grep ttypa

You can interpret the 'state' field from the 'ps(1)' manpages. A "Z" denotes a dead (defunct, or zombie) process.

A zombie is already dead and cannot be killed, even with the kill-of-last-resort ('kill -9').

In your 'ps' output as originally posted, I'd be more interested in the process's parent --- 27437. It may be that *that* process is waiting for a signal or resource so that *it* can continue and thus reap its (defunct) child.

Regards!

...JRF...

[Shivkumar]

Here is the output:

$ UNIX95= ps -efH -o pid,ppid,state,tty,args|grep ttypa
27437 27402 S ttypa ksh
27565 27437 Z ttypa
18104 18088 S ttypb grep ttypa
$

[James R. Ferguson]

Hi SHiv:

As Clay noted, try killing the *parent* process. I'd use:

# kill -1 27437
# kill -15 27437
# kill -9 27437

...in that order, testing for presence of the process after each step. I also agree with Clay insofar as killing the your process's parent (27437) may only cause your defunct process to be inherited by 'init'.

If your process still persists, repost the process hierarchy I first had you do.

Zombie processes are actually a *normal* transition state in a process's lifetime, although, they are fleeting when correct programming practices are followed.

It would be useful to know what HP-UX release this system is running, too.

Regards!

...JRF...

[Shivkumar]

The command #kill -1 27437 worked.

# uname -a
HP-UX BigGuy05 B.11.11 U 9000/800 1189444676 unlimited-user license
#

Could you please explain how it killed because i tried killing with $kill -9 pid/ppid and it didn't work earlier ?

Thanks,
Shiv

[A. Clay Stephenson]

What you describe is simply not possible. kill -9 cannot be ignored nor can it be caught (ie, given a signal handler other than the default) so there is no way that a kill -9 would be ignored and yet a kill -1 would be acted upon. However, you added one little clue that does suggest how this impossible situation becomes possible:

You said that $kill -9 PID fails but #kill -1 PID worked. Note the '$' and '#' (presumably ${PS1}) prompts; you did one as a regular user and the other as super-user. As a regular user, you did not have permission to signal a process that you did not own but as a super-user you could send such a signal.

[Shivkumar]

Clay,

You are right. Now i can recall that i had tried to kill with normal user id and not as a super user.

Regards,
Shiv