lkestel@gmuvax2.gmu.edu (Lawrence Kesteloot) (02/24/91)
I've got two problems that I haven't found any mention of in any of the
manuals:
1. I've got a program which needs to repeatedly fork() a child and
kill() it (sometimes the child ends normally). Each time the child
exits (either killed or ending normally), the system is left with a
Defunct process. The system seems to have an upper limit on the number
of processes in memory at any time, so I can only fork() limited number
of times. Is there any way to get rid of these defunct processes (they
go away when the program ends, but I don't want the program to end)?
2. I've got a program A which does a system("B &"); to spawn another
process in the background. It seems that A can't terminate until B
does. I would like to be able to get out of A and keep B running as if
I had run B & from the command line before running A. Is there any way
to do this? (What actually happens is that A pops up a window. When A
terminates, it's no longer in the "ps" list, but the window stays open
until I kill "B".)
E-Mail would be great, I'll post a summary. Thanks in advance.
Lawrence Kesteloot (lkestel@gmuvax2.gmu.edu)HERBER@FNALA.FNAL.GOV ("Randolph J. Herber, CD/DCD/SP, x2966") (02/26/91)
I attempted to respond to the original poster via e-mail. It was returned to me as undeliverable mail. Because I think that some readers of this mailing list may find the answer useful, I am sending it to mailing list. Randolph J. Herber, herber@fnalf.fnal.gov (also the acting FNAL postmaster). +From: SMTP%"Postmaster" 25-FEB-1991 10:08:50.34 +To: <HERBER> +CC: +Subj: Undeliverable Mail + +Date: Mon, 25 Feb 1991 10:08:39 CST +From: Postmaster@FNALA.FNAL.GOV +Subject: Undeliverable Mail +To: <HERBER> +Comment: Bad address -- <lkestel@louie.udel.edu> +Comment: Address refused by receiver: <lkestel@louie.udel.edu> (550 (USER) Unknown user name in "lkestel@louie.udel.edu") + +Start of returned message + + Date: Mon, 25 Feb 1991 10:08:26 CST + From: HERBER@FNALA.FNAL.GOV (Randolph J. Herber, CD/DCD/SP, x2966) + Message-Id: <910225100826.24e07268@FNALA.FNAL.GOV> + Subject: Re: Defunct messages and spawned processes + To: lkestel@louie.udel.edu + X-Vmsmail-To: SMTP%"lkestel@louie.udel.edu" + + Hi! + + The answer to your first problem is that you have to collect your zombie + children's death certificates before they can be laid to their rest. + + The answer to your second question is that a window will not close until + processes that have open file descriptors to it close them. + + Those were the head lines. Now the news in detail. + + In the kernel, there are two structures that are used to maintain a process's + context. The process block is used to maintain the data that must be + resident at all times. The user area is used to maintain the data that can + be swapped out or released after the process terminates execution. When + a process terminates, the exit status data is stored into the process block + and the user area is released. The process block is released only when the + parent of the process issues a wait(2) or wait3(2) system call to obtain this + information. While a process is in this state, frequently, it is refered to + as a "zombie." Sometimes, this status data is refered to as a "death + certificate." If a parent process dies (terminates) before a child process, + the child is sent to the orphanage which is run by init, process 1. Init + waits for the death of its children. For its natural children, it spawns + (gives birth to) new copies of those children as needed. This is governed + by /etc/inittab. For the orphans, it just circular files the death + certificates as the accounting data that is written at the same time is handled + by the kernel. + + The second program in your chain of program inherits any open files from + its parent process, the first program in your chain. What resources are + inherited from a parent is documented in fork(2). As the windows are normally + opened as stdin, stdout and stderr, these need to be closed by the child + to release the window. You may need to release the control terminal data + from the process block as well. For this I suggest that you research how + to write a daemon program. + + Randy Herber, fnalf.fnal.gov + +End of returned message