l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:00

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Zombie Processes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Zombie Processes

On Fri, 26 Jan 2001, Chris Lupo wrote:

> On Fri, 26 Jan 2001 jdnewmil@dcn.davis.ca.us wrote:
> > On Fri, 26 Jan 2001, Jan Wynholds wrote:
> > 
> > > Hey all:
> > > 
> > > Just had an eeeeenteresting thing happen to me at work
> > > yesterday.  Here is a brief rendition of the
> > > occurances (oh, this is on a RHL 6.2):
> > > 
> > > 1. A win98 program that interfaces a pgsql db crashed.
> > > 2. The TCP handler for the db records 'freaked out'
> > > and tried to kill the instance that was handling the
> > > rec's (from the win98 box).
> > > 3. The kill failed, and left a bunch of <defunct>
> > > (zombie) processes languishing.
> > 
> > Zombie processes are dead and gone... you are only seeing the record that
> > they existed, kept around so their parent process can read their exit
> > status.  This is a bug in the parent process, in that it did not extract
> > the exit status of the child process.
> > 
> This is true that zombie processes have their memory freed and will not be
> scheduled for execution.  But, it is not necessarily a bug in the parent
> process.  There may be something preventing the parent process from
> emitting a wait signal (resource contention or something).  It could also
> be that the parent process has already terminated or been killed, in which
> case the zombie child is inherited by the init process, and will go away
> soon. If the parent is still living, it's possible that whatever is
> keeping it from emitting the wait signal has the parent deadlocked, in
> which case the zombie children will remain in the process table until the
> parent is itself killed.

I regard all of these as bugs or flaws in the parent process, except the
temporary condition when init has not yet cleaned up the orphan.  The
parent should not allow itself to be deadlocked if it has child processes.  
Perhaps you would prefer to describe these behaviours as "documented

If a parent process doesn't want to be bothered with the child, it should
do the "spawn grandchild" trick described in the Unix FAQ.

Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
Work:<JeffN@endecon.com>              Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!