nohupに対する多数のスタック交換の回答があります。以下は参考のためにいくつかあります。
四半期に「&」を使用した場合、いつ「nohup」が必要ですか？
「exec&」の代わりに「nohup&」を使用する理由
正式な答えは、nohupを使用すると、端末が閉じたときにプロセスが終了するのを防ぎます。したがって、次のコマンドは次回の
nohup mycommand >& mycommand_output.txt &
ログイン時に引き続き実行され、後で確認できるように出力を保存します。
ただし、一部のキーストロークを保存すると、
mycommand >& mycommand_output.txt &
次回のログイン時にまだ実行されています。
それを防ぐために使用できるという点でnohupとは異なりますkill -HUP。再度ログインすると、ps -xそのプロセスのTTYが現在とマークされ、?そのプロセスがまだ端末に接続されていません。
シェルを終了してもプロセスが停止しないのはなぜですか？
nohupを使用しないと、プロセスが終了しないと安全に想定できますか？
私の現在の環境には、UbuntuシステムからDebianシステムへのSSH接続が含まれています。
ベストアンサー1
シェルを終了してもプロセスが停止しないのはなぜですか？
それはおそらくあなたがシェルにdisownそれについて話したからです。あるいは、セッション起動プロセスとして対話型ジョブ制御シェルを使用しないこともあります。
1980年代に世界的に定着したセッション+プロセスグループ結合モデルは、次のように動作します。会議の主催者プロセス。これがターミナルから切断信号を受け取る理由です。ライン規律端末が壊れたとき。これは、対応する信号を増幅して生成されたすべての「タスク」に信号を送信すると予想されます。インタラクティブ職業管理シェルはこれを行うことができます。他のほとんどのプログラムは、会議のホストミッションを実行したくありません。
セッションリーダーが中断信号を送信するときに、これらの「ジョブ」のプロセスが中断信号を無視するためnohupに使用されます。を使用すると、disownセッションリーダーシェルが作業を忘れてしまうので、最初から中断信号を送信しません。
nohupを使用しないと、プロセスが終了しないと安全に想定できますか？
いいえ。教育を受けていないdisown場合〜する切断信号は、セッションリーダ対話式ジョブ制御シェルプロセスによって送信されます。
さらに、システムの人々はカーネルセッションと同等のユーザースペースメカニズムを実装しようとしましたが、いくつかの試みが行われ、それによって（一部）システムオペレーティングシステムがより複雑になりました。 systemdセッションが中断されると、SIGHUPカーネルの接続規則のようにセッションリーダーにのみ送信されるのではなく、次にSIGTERM誤って送信されます。みんなプロセス、誤った表現閉鎖代わりに壊す。
SIGTERMもちろん、標準セッション+プロセスグループモデルですべてのプロセスに対してシステムがシャットダウンした場合、どうなりますか？これにより、拒否されたプロセスや中断信号を無視したプロセスを含むすべてのプロセスが終了します。もちろん、disown編集も編集もしないプロセスも終了します。nohup