0

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 adapted by init process. But what I don't understand is, what is the problem if the child process becomes orphan and gets adapted by initprocess. Why should it be attached to the parent process itself until it terminates?

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.