Getting rid of a <defunct> process

James Logan III logan at vsedev.VSE.COM
Tue Feb 21 14:19:31 AEST 1989


In article <2565 at spdcc.SPDCC.COM> dyer at ursa-major.spdcc.COM (Steve Dyer) writes:
# In article <102 at avatar.UUCP> kory at 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 at vsedev.vse.com
VSE Software Development Lab        uucp:  ..!uunet!vsedev!logan
(703) 418-0002                      inet:  logan%vsedev.vse.com at uunet.uu.net



More information about the Comp.unix.questions mailing list