プロセスは「SIGHUP で強制終了」されません。少なくとも、厳密な意味ではそうではありません。むしろ、接続が切断されると、端末の制御プロセス (この場合は Bash) にハングアップ信号*が送信されます。これは、一般に「HUP 信号」または単に SIGHUP と省略されます。
これで、プロセスがシグナルを受信すると、任意の方法で処理できます**。ほとんどのシグナル (HUP を含む) のデフォルトは、すぐに終了することです。ただし、プログラムは代わりにシグナルを自由に無視したり、ある種のシグナル ハンドラー関数を実行したりすることもできます。
Bash は最後のオプションを選択します。その HUP シグナル ハンドラは、「huponexit」オプションが true かどうかを確認し、true の場合は、子プロセスのそれぞれに SIGHUP を送信します。それが終わって初めて、Bash は終了します。
同様に、各子プロセスは、シグナルを受信したときに、必要なことを自由に実行できます。既定値のままにする (つまり、すぐに終了する)、無視する、またはシグナル ハンドラーを実行します。
Nohup は、子プロセスのデフォルト アクションを「無視」に変更するだけです。ただし、子プロセスが実行されると、シグナルに対する独自の応答を自由に変更できます。
これが、nohup で実行したにもかかわらず、一部のプログラムが終了する理由だと思います:
<オール>ここで「disown」の出番です。huponexit オプションに関係なく、Bash によって disown されたプロセスには HUP シグナルが送信されません。したがって、プログラムが独自のシグナル ハンドラーを設定したとしても、シグナルが実際に送信されることはないため、ハンドラーは実行されません。ただし、プログラムがログアウトしているユーザーにテキストを表示しようとすると、I/O エラーが発生し、いずれにせよプログラムが終了する可能性があることに注意してください。
* はい、質問する前に言っておきますが、「ハングアップ」という用語は、UNIX のダイヤルアップ メインフレームの時代から残っています。
**とにかく、ほとんどの信号。たとえば、SIGKILL 常に プログラムをただちに終了させます、ピリオド。
ポイント 1 から 4 は正しいです。ポイント 5 については何も知りません。最後のポイントとしては、優れたアプリケーション、スクリーン 、接続を終了する方法に関係なく、すべてのプロセスを自然な終了まで実行させることができます。画面はリポジトリにあります。
screen の man の説明は読みにくいですが、とりわけ次のように述べています。
<ブロック引用>screen が呼び出されると、シェル (または指定されたコマンド) を含む単一のウィンドウが作成され、通常どおりにプログラムを使用できるように邪魔になりません。その後、いつでも、他のプログラム (より多くのシェルを含む) を含む新しい (フルスクリーン) ウィンドウを作成したり、既存のウィンドウを強制終了したり、ウィンドウのリストを表示したり、出力ログのオンとオフを切り替えたり、テキストをコピーして貼り付けたりすることができます。すべてのウィンドウは、互いに完全に独立してプログラムを実行します。ウィンドウが現在表示されていないときや、画面全体がセッションがユーザーの端末から切り離されている .プログラムが終了すると、screen (デフォルトでは) はそれを含んでいたウィンドウを kill します。このウィンドウが最前面にあった場合、表示は前のウィンドウに切り替わります。何も残っていない場合、画面は終了します。
最も重要な部分を強調しました:コマンド Ctrl+a+d でウィンドウをデタッチできます。その後、セッションを強制終了/ログアウトすることができます。デタッチされたウィンドウは、内部のプログラムがまだ実行されている状態で存続し続けます。たとえば、新しい ssh セッションを開始することによって再接続する場合、コマンド screen -r 以前に分離されていた画面セッションを再開し、標準エラー/出力へのすべての出力が明確に表示されます。