2

I know there is no enforcement for the parent process to wait until all its child process terminates. However it's a convention followed. Furthermore, I know that if parent process terminates before it's child process terminates, then the child process become orphan and it will be adopted by init process. But what I don't understand is, what is the problem if the child process becomes orphan and gets adopted by the init process. Why should it be attached to the parent process itself until it terminates?

cassepipe
  • 180
Darshan L
  • 279

2 Answers2

3

The main reason for this convention is that, if a process forks children, typically the child processes are doing part of the job that the main process was expected to do.  Did you have any example of a program that forks in mind?

Here are some examples:

  • A program that does intense computation might fork multiple copies of itself in order to run on multiple CPUs/cores simultaneously.  (It might be more conventional to use threads for this, but it can certainly be done with forked processes.)  Such a program might be designed so that each process just writes an independent output.  But it would also be common for the main process to wait for all the children to finish and then consolidate their results.
  • Programs like netcat sometimes have one process reading from host A and writing to host B, and one process reading from host B and writing to host A.  (Yes, this could also be done with threads.)
  • Trivially, in the cases of find -exec and xargs, the (main) program's job is to run the subordinate program and wait for it to finish.  Imagine what would happen if a user said 
    find . -type f -exec cp {} /backup ';'  &&  rm -r .

    and the find exited without waiting for all the copies to finish.

In these cases (and others), the main program's job isn't done until any and all child processes have completed.  Therefore, the program must not exit until it has waited for all the child process(es).

Of course this isn't the only way fork is used.  It is common for network servers (e.g., FTP and mail) to have one main process that listens for incoming connections, and then to fork a child each time it gets a client connection.  Such child processes could terminate at arbitrary times (determined by the clients), and there is no reason for the main process to wait for its children.

The bit about what "parent"/reaper process a child process is associated with when it terminates is not really an issue.

G-Man Says 'Reinstate Monica'
  • 22,870
1

The main reason for this convention is that if the parent process terminates before the children, the children's exit code will be lost and the child process may remain a zombie for a while.

After a child process terminates, it will stay around (and consume memory) until the exit code is read. This is what is referred to as a zombie process - dead, but not reaped (removed).

It is generally the parent process's responsibility to read the exit code and allow the zombie process to completely go away. Since the parent should keep track of the children, it will hopefully be quick to clean up. If the parent process does not do that, you have a resource leak.

If the parent process terminates before the child does, init will indeed take over that responsibility, but it may not be aware of that immediately, so the child may remain a zombie for longer, and thus take up more resources.

Edit: for clarification, a process in zombie state does not keep all of its memory around - most of it is freed before the process becomes a zombie. It is the entry in the process table that remains. The more process table entries there are, the more time the kernel will need for process-related activities.

Kevin Keane
  • 635
  • I'm not sure that what you're saying entirely makes sense.   (1) Parent processes don't "keep track" of child processes per se, or at least they don't need to.  The kernel handles the association.   (2) In what sense do you believe that the init process becomes aware that it has taken over responsibility for reaping orphaned processes?  AFAIK, this is just a matter of the kernel changing the child process's PPID to 1.  The only delay would occur if init was busy doing other things, and I believe that that's rare.  (Can you specify what init might be doing?) … (Cont’d) – G-Man Says 'Reinstate Monica' Oct 20 '21 at 00:18
  • (Cont’d) …  Conversely, if the child process's actual parent is doing anything other than calling wait() or something equivalent — for example, waiting for data from a network connection — *that* might cause the zombie process(es) to persist for a while. (3) I didn't downvote you.  In fact, my answer got downvoted the same time yours did (probably by the same person). – G-Man Says 'Reinstate Monica' Oct 20 '21 at 00:18
  • @G-ManSays'ReinstateMonica' Note that I said "should" keep track of the children. You are right that the kernel does keep track of the children. But in order to retrieve the return value (and therefore "dezombify" the child process), the parent also needs to know which children it started. Usually, that means tracking the PIDs of all the children (although sometimes it may be better for the parent to retrieve the list of children from the kernel). – Kevin Keane Oct 20 '21 at 00:26
  • "the parent also needs to know which children it started." No, it doesn't. All it has to do is call wait() or something equivalent, and the kernel will find a child (or descendant) process that needs to be handled. – G-Man Says 'Reinstate Monica' Oct 20 '21 at 00:37