16

我有一个 bash 脚本 start.sh，它看起来像这样：

for thing in foo bar; do
    {
        background_processor $thing
        cleanup_on_exit $thing
    } &
done

这就是我想要的：我运行 start.sh，它以代码 0 退出，两个子 shell 在后台运行。每个子shell运行background_processor，当它退出时，它运行cleanup_on_exit。即使我退出最初运行 start.sh 的终端（即使那是 ssh 连接），这也有效。

然后我尝试了这个：

ssh user@host "start.sh"

这有效，除了start.sh退出之后，ssh 显然还等待子shell 退出。我真的不明白为什么。退出start.sh后，子shell 成为pid 1 的子shell，甚至没有为它们分配tty ......所以我不明白它们是如何与我的ssh 连接相关联的。

我后来试过这个：

ssh -t user@host "start.sh"

现在进程有一个分配的伪终端。现在，我发现 ssh 确实会在退出后立即start.sh退出，但它也会杀死子进程。

我猜想在后一种情况下正在向子进程发送 SIGHUP，所以我这样做了：

ssh -t user@host "nohup start.sh"

这确实有效！所以，我有一个解决我的实际问题的方法，但我想在这里掌握 SIGHUP/tty 东西的微妙之处。

总之，我的问题是：

  1. 为什么 ssh（没有 -t）即使在start.sh退出后仍等待子进程，即使它们的父 pid 为 1？
  2. 为什么 ssh (with -t) 会杀死子进程，显然是使用 SIGHUP，即使当我从终端运行它们并注销该终端时不会发生这种情况？
4

3 回答 3

23

我想我现在可以解释了！我必须通过阅读The TTY Demystified来了解一下什么是会话和流程组。

  1. 为什么即使在 start.sh 退出后，ssh（没有 -t）也会等待子进程，即使它们的父 pid 为 1？

因为没有 tty，ssh 通过管道（然后由子进程继承）连接到 shell 进程的 stdin/stdout/stderr，并且我正在使用的 OpenSSH 版本（OpenSSH_4.3p2）等待这些套接字关闭之前退出。一些早期版本的 OpenSSH 的行为方式并非如此。有一个很好的解释，有理由，here。

相反，当使用交互式登录（或ssh -t）时，ssh 和进程正在使用 TTY，因此无需等待管道。

我可以通过重定向流来恢复我想要的行为。此变体立即返回：ssh user@host "start.sh < /dev/null > /dev/null 2>&1"

  1. 为什么 ssh (with -t) 会杀死子进程，显然是使用 SIGHUP，即使当我从终端运行它们并注销该终端时不会发生这种情况？

因为 bash 以非交互模式启动，这意味着默认情况下禁用作业控制，因此子进程与父 bash 进程（即会话负责人）位于同一进程组中。当父 bash 进程退出时，内核将 SIGHUP 发送到其进程组（位于前台），如下所述setpgid(2)：

如果会话有一个控制终端，... [and] 会话领导者退出，SIGHUP 信号将被发送到控制终端的前台进程组中的每个进程。

相反，当使用交互式登录时，bash 处于交互模式，这意味着默认情况下启用作业控制，因此子进程进入单独的进程组，并且在我退出时永远不会收到 SIGHUP。

我可以通过set -m在 bash 中启用作业控制来恢复我想要的行为。如果我添加set -m到start.shssh 退出时，孩子们将不再被杀死。

谜团解开了:)

于 2013-02-14T02:16:11.397 回答
0

我怀疑（但我假设）当没有 tty 时，bash 会将 SIGHUP 传递给您的分叉进程，该进程本身正在处理信号，并悄悄地忽略它并继续占用 SSH 会话。

然而，在你和进程之间有一个 tty，tty 驱动程序正在拦截 SIGHUP，意识到它已经失去了用户，并在没有 ssh 会话作为父进程的情况下分叉自己运行。

于 2013-02-05T01:52:30.770 回答
0

在您不希望此 SIGHUP 发生的任何呼叫前加上“nohup”。

于 2014-06-23T15:17:09.637 回答