Linux Process Groups – Does Kernel Sending SIGHUP to Orphaned Process Group Terminate All Processes?

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.