web-dev-qa-db-ja.com

screen / nohupにもかかわらず、ssh切断でプロセスが強制終了されました

私はかなり奇妙な状況に直面しています：

  • sshからビーグルボーンへ（詳細：uname -a = "Linux beaglebone 3.2.34＃1 Wed Nov 21 14:17:11 CET 2012 armv7l GNU/Linux"、sshサーバー：Dropbear sshd v2012.55）
  • 画面、Nohup、または/etc/init.d/からあらゆる種類のプロセスを起動します
  • ログアウト
  • それに再ssh
  • プロセスがもう存在しないことを確認してください。

2番目のssh接続を使用すると、起動されたプロセスが切断時に強制終了されることがわかります。

シェルが終了したときにバックグラウンドジョブが強制終了されるか、強制終了されるかを正確に決定するものは何ですか？ のような投稿を見ましたが、それでもこの動作を理解できません。これは明らかに方法ではありませんscreenおよびその他の所有されていないプロセスが機能するはずです。

$ shopt huponexit
huponexit       off

プロセスを永続化するためにcronコマンドを使用することに頼らなければなりませんでした

切断時に切り離されたプロセスが強制終了されるのはなぜですか？

他に探すべきものがありますか？

linuxsshdisplay
1
NotSqrt

奇妙なNohupが機能しないようですが、次のように簡単にテストできます。

  { sleep 999; echo $? > exitcode ; } &
  fuser -1 -k /bin/sleep
  expr $(cat exitcode) - 128

これにより、戻りコードから128を引いた値が出力されます。これは、それを強制終了したシグナルの番号です。次の手順を実行するだけで、それらを一覧表示できます。

  kill -l

代わりにこれを試してください：

  rm exitcode
  { Nohup sleep 999; echo $? > exitcode; } &
  fuser -1 -k /bin/sleep
  ls -l exitcode

Nohupが機能する場合、この時点でそのようなファイルはないと通知されます。次の手順でこれを再確認できます。

  fuser -15 -k /bin/sleep
  expr $(cat exitcode) -128

この値が15であることがわかります。

編集

最後のコメントは非常に明白でした。つまり、SIGHUPはプロセス（この場合はスリープ）に送信されるのではなく、シェルに直接送信されます。もちろん、これはDropberarによって簡単に行うことができます。少しの調査によると、Dropbearは実際にログオフ時にすべてのユーザープロセスを強制終了します。

行を追加することで、この厄介な機能を変えることができます

 KillMode=process

/lib/systemd/[email protected]ファイルのServiceスタンザの最後にあります。次に、Dropbearを再起動または再起動します。

0
MariusMatutiae