nohup
SSHでバックグラウンドコマンドを使用する必要性を理解したいと思います。 CentOSの私のシェルはcshです。
次のバックグラウンドコマンドは、sshが終了した後も引き続き実行されます。
nohup
私はコマンドの前に付いている場合にのみこれが起こると予想しました。どのシナリオで
nohup
必要ですか?ssh host 'sleep 80 >& /dev/null &'
また、対話型シェルを試みましたが、sshが終了した後もバックグラウンドジョブのPIDがまだホストに存在します。
ssh host sleep 80 >& /dev/null & exit
kill -HUP PID
また、対話型セッションを終了する代わりにを使用してみましたが、exit
sshが終了した後もバックグラウンドジョブのPIDがまだホストに存在します。
私は何が間違っていましたか?
答え1
誰も背景デフォルトでは、セッションリーダー(シェル)が終了した場合、またはその制御端末が解体されても、プロセスグループ(タスク)は終了しません。
これはいくつかの特別な場合にのみ発生します。
(1)バックグラウンドタスクは停止SIGHUP
SIGCONT
、この場合、一対の信号で送信されます。コア。プロセスが信号を捕捉できないか無視すると、SIGHUP
プロセスは終了します。
停止したジョブは、停止したプロセスを含むすべてのジョブとして定義されます。プロセス眠るnanosleep(2)
またはなどのブロックシステムコールは停止されたread(2)
とは見なされません。
(2)プロセスが存在しなくなった端末で読み書きを試みると、エラーのため終了します。
(サム)この仕事は実際に展望働くこれコアSIGHUP
セッションリーダー/制御プロセス(シェルなど)が終了すると、フォアグラウンドプロセスグループにシグナルを送信します。SIGHUP
制御端末が取り外されると、制御プロセス自体が信号を受信し、これは通常端末を終了する。
で始まるコマンドも&
実際には展望ジョブ制御なしでシェルから始まる場合(csh以外のほとんどのシェルではランタイムのデフォルト)スクリプトそしてサブシェル)。
(4)bash
または、それ自体が信号を受信するzsh
場合(シェルは上記の3番目の項目による制御プロセスです)、または終了するとき(後者はのデフォルト値のみであり、デフォルト値ではなくオプションの適用を受けます)などのシェルを使用しています。強く打つ)。SIGHUP
SIGHUP
zsh
shopt huponexit
これシェル(実際csh
またはtcsh
)そのような行動はありません。bash
またはからzsh
。 (実際ではtcsh
ないcsh
)組み込みコマンドランチャーを使用して、シェルが終了しhup
たときにそれを実行できます。
tcsh% hup sleep 3600 &
tcsh% exit
$ pgrep sleep
[nothing]
(5)初期化システムは、終了したユーザーセッションをきちんと整理します。基本構成ではシステムすべてのプロセスに信号を送信します。範囲遅延が1つ続くので、SIGTERM
とにかく役に立ちません。また、systemdのアイデアはSIGKILL
nohup
範囲Unixプロセスセッションと一致しないため、コマンドを実行してもsetsid(1)
エスケープされません。
オプションのデフォルト値を調整することで、KillUserProcesses=yes
systemdKillMode=control-group
のKillSignal=SIGTERM
動作を変更できますSendSIGKILL=yes
。