Xref: utzoo comp.unix.questions:11660 comp.unix.wizards:14653 comp.unix.xenix:4932
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix
Subject: Re: Getting rid of a <defunct> process
Keywords: defunct process
Message-ID: <2565@spdcc.SPDCC.COM>
Date: 12 Feb 89 22:35:46 GMT
References: <102@avatar.UUCP>
Reply-To: dyer@ursa-major.spdcc.COM (Steve Dyer)
Distribution: usa
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 29

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.

Defunct, or "zombie", processes take up a process slot, but no other resources.
Nevertheless, process slots themselves may be scare resources on a busy
system (especially if you expect to run a lot of programs like the one
you describe.)

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.

I've never really liked this SYSV behavior, since it overloads signal
semantics with stuff they were never designed to have, but it's there
and it works...

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu