0

In The Linux Programming Interface

To see why orphaned process groups are important, we need to view things from the perspective of shell job control. Consider the following scenario based on Figure 34-3:

  1. Before the parent process exits, the child was stopped (perhaps because the parent sent it a stop signal).

  2. When the parent process exits, the shell removes the parent’s process group from its list of jobs. The child is adopted by init and becomes a background process for the terminal. The process group containing the child is orphaned.

  3. At this point, there is no process that monitors the state of the stopped child via wait().

Since the shell did not create the child process, it is not aware of the child’s existence or that the child is part of the same process group as the deceased parent. Furthermore, the init process checks only for a terminated child, and then reaps the resulting zombie process. Consequently, the stopped child might languish forever, since no other process knows to send it a SIGCONT signal in order to cause it to resume execution.

Even if a stopped process in an orphaned process group has a still-living parent in a different session, that parent is not guaranteed to be able to send SIGCONT to the stopped child. A process may send SIGCONT to any other process in the same session, but if the child is in a different session, the normal rules for sending signals apply (Section 20.5), so the parent may not be able to send a signal to the child if the child is a privileged process that has changed its credentials.

To prevent scenarios such as the one described above, SUSv3 specifies that if a process group becomes orphaned and has any stopped members, then all members of the group are sent a SIGHUP signal, to inform them that they have become disconnected from their session, followed by a SIGCONT signal, to ensure that they resume execution. If the orphaned process group doesn’t have any stopped members, no signals are sent.

The default action to SIGHUP is termination. So does kernel implicitly sending SIGHUP to a process group that becomes orphaned and contains a stopped process mean that

  • those processes in the group and without their own SIGHUP dispositions will be terminated? Will any stopped process in the group be first resumed by SIGCONT and terminated by SIGHUP?

  • to make the processes in the group survive, they need to have their own SIGHUP dispositions or ignore SIGHUP?

Thanks.

  • Yes & Yes. You can see the Notes in my answer here for link(s) to the linux source implementing that (the comments from the linux source and the actual code are much better than that prose or my glossing over it). – mosvy Dec 22 '18 at 17:11
-1

Please let me turn mosvy's comment into an answer:

Yes & Yes. You can see the Notes in my answer here for link(s) to the linux source implementing that (the comments from the linux source and the actual code are much better than that prose or my glossing over it)

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.