What does reaping children imply?

Question

I have just had a lecture that sums reaping as:

Reaping

• Performed by parent on terminated child (using wait or waitpid)

• Parent is given exit status information

• Kernel then deletes zombie child process

So I understand that reaping is done by calling wait or waitpid from the parent process after which the kernel deletes the zombie process. If this actually is the case, that reaping is done only when calling wait or waitpid, why do the child processes actually go away after returning in the entry function - I mean that indeed does seem as if the child processes have been reaped and thus no resources are wasted even though the parent process may not be waiting.

So is "reaping" only possible when calling wait or waitpid? If processes are "reaped" as long as they return and exit from their entry function (which I assume all processes do) - what is the point of talking about "reaping" as if it was something special?

Nepotism

Answer 1

The child process does not fully "go away" when it exits. It ceases to exist as a running process, and most/all of its resources (memory, open files, etc.) are released, but it still remains in the process table. It remains in the process table because that's where its exit status is stored, so that the parent can retrieve it by calling one of the wait variants. If the parent fails to call wait, the process table entry sticks around — and that's what makes it a "zombie".

I said that most/all of its resources are released, but the one resource that's definitely still consumed is that process table slot.

As long as the (dead) child's parent exists, the kernel doesn't know that the parent isn't going to call wait eventually, so the process table slot has to stay there, so that the eventual call to wait (if there is one) can return the proper exit status.

If the parent eventually exits (without ever calling wait), the child will be inherited by the grandparent, which is usually a "master" process like the shell, or init, that does routinely call wait and that will finally "reap" the poor young zombie.

So, yes, it really is true that the only way for the parent to properly "reap" the child is, just as was said in your lecture, to call one of the wait functions. (Or to exit, but that's not an option if the parent is long-running.)

Footnote: I said "the child will be inherited by the grandparent", but I think I was wrong, there. Under Unix and Linux, orphaned processes are generally always inherited by pid 1, aka init.

Marcy

And the only way to remove it from the process table is by calling one of the wait functions in the parent process? – Nepotism

@npp> Yes. And eventually, if no other process deals with that, it will go all the way up to process 1, which will do it. – Scat

"orphaned processes are generally always inherited by pid 1", yes, unless an ancestor between the child and init has called prctl(PR_SET_CHILD_SUBREAPER ) – Babbage

@MagnusKronqvist Thank you very much for that note. I have been speculating about the need for something precisely like this prctl(PR_SET_CHILD_SUBREAPER). I didn't realize it existed already. – Marcy

Answer 2

The purpose of the wait*() call is to allow the child process to report a status back to the parent process. When the child process exits, the operating system holds that status data in a little data structure until the parent reads it. Reaping in that sense is cleaning out that little data structure.

If the parent does not care about waiting for status from the child, the code could be written in a way to allow the parent to ignore the status, and so the reaping occurs semi-automatically. One way is to ignore the SIGCHLD signal.

Another way is to perform a double-fork to create a grandchild process instead. When doing this, the "parent" does a blocking wait() after a call to fork(). Then, the child performs another fork() to create the grandchild and then immediately exits, causing the parent to unblock. The grandchild now does the real work, and is automatically reaped by the init process.

Ellie