Xref: utzoo comp.unix.questions:11806 comp.unix.wizards:14795 comp.unix.xenix:5071
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!ncar!tank!mimsy!haven!vrdxhq!vsedev!logan
From: logan@vsedev.VSE.COM (James Logan III)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix
Subject: Re: Getting rid of a <defunct> process
Keywords: defunct process
Message-ID: <1328@vsedev.VSE.COM>
Date: 21 Feb 89 04:19:31 GMT
References: <102@avatar.UUCP> <2565@spdcc.SPDCC.COM>
Reply-To: logan@vsedev.VSE.COM (James Logan III)
Distribution: usa
Organization: VSE Software Development Lab
Lines: 32

In article <2565@spdcc.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
# In article <102@avatar.UUCP> kory@avatar.UUCP (Kory Hamzeh) writes:
# >I have written an application which forks and execs off many subtasks.
# >The main process (the parent which does all of the forks) can not
# >do a wait() because I can't get blocked for anything. Well, this results
# >in a lot of "<defunct>" processes in the process table when the child
# >exits. Is there any way to get rid of these processes? If not, will they take
# >up any core space? I assume they will take up a slot in the process table.
# 
# You can change the behavior of wait and exit by having the parent
# process (the one doing the forking) call signal(SIGCLD, SIG_IGN):
# now, child processes which exit will not leave zombies around, and
# the wait system call in the parent will not return until all children
# have died.  If the parent never performs a wait(), and you're not
# interested in the exit status of your children, this will give you
# the behavior you desire.

Unless you do this under XENIX...  I had a problem with this a
couple of months ago.  When I ignored the SIGCLD signal and
called system("some_program"), the defunct processes were still
hanging around.  

I had to fork, call system() in the child, and then ignore SIGCLD
in the parent to solve the problem (if I remember correctly).  I
believe the problem is in the SCO Bourne shell since this
does not occur on any other System V machine I've used.   

			-Jim
-- 
Jim Logan                           logan@vsedev.vse.com
VSE Software Development Lab        uucp:  ..!uunet!vsedev!logan
(703) 418-0002                      inet:  logan%vsedev.vse.com@uunet.uu.net