デフォルトでは、カーネルは孤立して停止したプロセスを含むプロセスグループにSIGHUPを送信してすべてのプロセスを終了しますか？

Linuxプログラミングインターフェースから

孤立したプロセスグループが重要な理由を理解するには、シェルジョブ制御の観点から物事を調べる必要があります。図 34-3 に基づいて、次のシナリオを検討します。

1. 親プロセスが終了する前に子プロセスが停止します（おそらく親プロセスが停止信号を送信したため）。

2. 親プロセスが終了すると、シェルはタスクリストから親プロセスのプロセスグループを削除します。子プロセスはinitによって採用され、端末のバックグラウンドプロセスになります。子プロセスを含むプロセスグループは隔離されます。

3. この時点で、どのプロセスもwait（）を介して停止した子プロセスの状態を監視しません。

シェルは子プロセスを作成しないため、子プロセスが存在するのか、子プロセスが死んだ親プロセスと同じプロセスグループに属しているのかはわかりません。また、initプロセスは終了した子プロセスのみを確認し、生成されたゾンビプロセスを取得します。したがって、停止したサブプロセスは、実行を再開するためにSIGCONTシグナルを送信する方法を知る他のプロセスがないため、永遠に停滞する可能性があります。

孤立したプロセスグループの停止プロセスに他のセッションでまだアクティブな親プロセスがある場合でも、親プロセスが停止した子プロセスにSIGCONTを送信できるという保証はありません。プロセスは同じセッション内の他のプロセスにSIGCONTを送信できますが、子プロセスが別のセッションにある場合はシグナリングの一般的な規則（セクション20.5）が適用されるため、親プロセスは他のセッションにシグナルを送信できない可能性があります。子プロセスが資格情報が変更された特権プロセスである場合は、子プロセスです。

上記の状況を回避するために、SUSv3は次のように指定します。もしプロセスグループが分離され、停止したメンバーがあります。 それからグループのすべてのメンバーは SIGHUP シグナルを受け取り、セッションが切断されたことを通知し、SIGCONT シグナルを送信して実行を再開します。孤児プロセスグループに停止したメンバーがない場合、シグナルは送信されません。

SIGHUP の基本操作は終了です。それでは、カーネルが孤立して停止したプロセスを含むプロセスグループに暗黙的にSIGHUPを送信するという意味ですか？

• 独自のSIGHUP設定がない場合、グループ内の対応するプロセスは終了しますか？グループで停止したプロセスは最初にSIGCONTによって再開され、SIGHUPによって終了されますか？

• グループのプロセスを維持するには、独自のSIGHUP設定が必要ですか、それともSIGHUPを無視しますか？

ありがとうございます。