Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!ron@BRL.ARPA
From: ron@BRL.ARPA (Ron Natalie)
Newsgroups: net.unix
Subject: Re:  UNIX question
Message-ID: <567@brl-tgr.ARPA>
Date: Wed, 11-Dec-85 11:18:32 EST
Article-I.D.: brl-tgr.567
Posted: Wed Dec 11 11:18:32 1985
Date-Received: Fri, 13-Dec-85 20:04:38 EST
Sender: news@brl-tgr.ARPA
Lines: 32

Processes that die stay around until their status gets "inheritted."
If the parent process (the one that did the fork) is still alive,
it must execute a wait system call to get the information.  If the
parent dies without waiting for the child, then the child gets
inheritted by the "orphanage" process, init, which once the system
is running is always waiting for processes to die.

Killing these ZOMBIE (dead, but not inheritted) processes is ineffective
since they are already dead.  They count against you because until they
are inheritted, they consume one of a finite number of process slots on
the system, which is what the process limit is protecting.

You should fix the parent program such that it either waits for the
dead children, or use the following frequently used kludge:

	FORK
	if CHILD then
		FORK
		if CHILD then
			EXECUTE SUBPROCESS CODE
		else
			EXIT
		endif
	else
		WAIT
	endif

Here the process forks a second process which forks the spawned job.
The middle process dies, making the spawned job an orphan who will
be eaten by init.

=Ron