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