シェルを終了した後、バックグラウンドジョブはどうなりますか？

私の理解では、ジョブは特定のシェルから開始されるパイプラインfgでありbg、これらのジョブ（、、Ctrl-Z）をこのシェル内から管理できます。ジョブは複数のプロセス/コマンドで構成できます。

私の質問は、シェルを含む元のシェルが終了すると、これらのジョブはどうなるのですか？huponexitが設定されていないため、シェルの終了後もバックグラウンドプロセスが実行を続けるとします。

私がやったとしましょう：

$ run.sh | grep 'abc' &
[1] job_id

次に、このシェルを終了します。新しいシェルを入力して実行するjobsと、何も表示されなくなります。しかし、私はps aux | grep run.shこのプロセスが実行されていることを確認できます。またps aux | grep grep、grep 'abc'実行プロセスも実行して確認できます。

パイプライン全体のジョブIDを取得して、一度に終了できるようにする方法はありますか？または、元のシェルを終了したら、別のシェルとは別にすべてのプロセスを終了する必要がありますか？（私は後者を試しましたが、うまくいきますが、すべてのプロセスを追跡するのは面倒のようです。）

シェルが終了すると、HUPシグナルがバックグラウンドジョブに送信され、これによりジョブが終了する場合があります。SIGHUPシグナルは、シェル自体がSIGHUPを受信した場合にのみ送信されます。つまり、ターミナルが消えた場合（たとえば、ターミナルエミュレータープロセスが終了した場合）だけで、シェルを正常に終了した場合（exit組み込みコマンドまたはCtrl+ を入力した場合）は送信されませんD。ログアウト時にSIGHUPがジョブに送信されないのはどの場合ですか？を参照してください。そして、子プロセスが親と一緒に死ぬUNIXの変種はありますか？詳細については。bashでは、huponexitオプションを設定して、SIGHUPを通常の終了時にバックグラウンドジョブに送信することもできます。ksh、bash、zshでは、disownジョブでSIGHUPを送信するジョブのリストから削除します。SIGHUPを受信するプロセスは、シグナルを無視またはキャッチする可能性があり、その場合、プロセスは停止しません。nohupプログラムを実行するときに使用すると、SIGHUPの影響を受けなくなります。

SIGHUPの可能性があるためにプロセスが強制終了されない場合、そのプロセスは遅れたままです。シェルでジョブ番号に関連付ける必要はありません。

端末にアクセスしようとしたが、端末が存在しなくなった場合、プロセスは引き続き停止する可能性があります。それは、プログラムが存在しない端末にどのように反応するかによって異なります。

ジョブに複数のプロセス（パイプラインなど）が含まれている場合、これらのプロセスはすべて1つのプロセスグループに含まれます。プロセスグループは、関連する複数のプロセスで構成されるシェルジョブの概念を正確に捉えるために発明されました。たとえばで、 -あなたはそれらのプロセスグループID（グループの最初のプロセスの通常のプロセスID PGID）を表示することにより、プロセスグループによってグループ化されたプロセスを見ることができますps lLinuxの下など何かps -o pid,pgid,tty,etime,comm移植性。

に負の引数を渡すと、グループ内のすべてのプロセスを強制終了できますkill。たとえば、強制終了するパイプラインのPGIDが1234であると判断した場合は、次のコマンドで強制終了できます。

kill -TERM -1234

一般的にはまだ動作しますが、忘れた場合や変更した場合はnohupを使用してください。

mike@mike-laptop4:~$ sleep 500
^Z
[1]+  Stopped                 sleep 500
mike@mike-laptop4:~$ bg
[1]+ sleep 500 &
mike@mike-laptop4:~$ jobs
[1]+  Running                 sleep 500 &
mike@mike-laptop4:~$ disown %1
mike@mike-laptop4:~$ jobs
mike@mike-laptop4:~$