☰

尽管有 screen/nohup，ssh 断开连接时进程仍被终止

tag-icon • tag-icon linux ssh display
尽管有 screen/nohup，ssh 断开连接时进程仍被终止

我面临一个相当奇怪的情况：

  • ssh 到 beaglebone（详细信息：uname -a = “Linux beaglebone 3.2.34 #1 Wed Nov 21 14:17:11 CET 2012 armv7l GNU/Linux”，ssh 服务器：Dropbear sshd v2012.55）
  • 通过 screen、nohup 或 /etc/init.d/ 启动任何类型的进程
  • 登出
  • 重新 ssh 进入
  • 观察到该过程不再存在..

当使用第二个 ssh 连接时，我可以观察到启动的进程在断开连接时被终止。

我见过类似的帖子什么确切地决定了后台作业是否在退出 shell 时被终止或被终止？，但仍然无法理解这种行为，这显然不是screen其他被抛弃的进程应该工作的方式。

$ shopt huponexit
huponexit       off

我不得不使用 cron 命令来维持这个过程

为什么断开连接时分离的进程会被终止？

您还发现其他值得寻找的东西吗？

答案1

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 不是发送给进程（在本例中为休眠），而是直接发送给你的 shell。当然，这只能由 Dropberar 来完成。经过一番研究，Dropbear 确实会在注销时终止所有用户进程。

您可以通过添加以下行来关闭这个烦人的功能

 KillMode=process

在 /lib/systemd/ 中的 Service 节末尾[电子邮件保护]文件。然后重新启动或重启 Dropbear。

相关内容