如果分配了伪 tty，为什么通过 ssh 运行后台任务会失败？

Question

我最近在通过 ssh 运行命令时遇到了一些有点奇怪的行为。 我很想听听对以下行为的任何解释。

按预期运行ssh localhost 'touch foobar &'会创建一个名为foobar的文件：

[bob@server ~]$ ssh localhost 'touch foobar &'
[bob@server ~]$ ls foobar
foobar

但是，运行相同的命令但使用-t选项强制伪 tty 分配无法创建foobar ：

[bob@server ~]$ ssh -t localhost 'touch foobar &'
Connection to localhost closed.
[bob@server ~]$ echo $?
0
[bob@server ~]$ ls foobar
ls: cannot access foobar: No such file or directory

我目前的理论是，因为触摸进程被后台处理，所以在进程有机会运行之前分配和未分配伪 tty。 当然，添加一秒钟的睡眠可以让触摸按预期运行：

[bob@pidora ~]$ ssh -t localhost 'touch foobar & sleep 1'
Connection to localhost closed.
[bob@pidora ~]$ ls foobar
foobar

如果有人有明确的解释，我会非常有兴趣听到它。 谢谢。

Answer 1

哦，那是一个很好的。

这与进程组的工作方式，bash在使用-c作为非交互式shell调用时的行为以及输入命令中&的效果有关。

答案假设您熟悉UNIX中作业控制的工作原理; 如果你不是，那么这是一个高级视图：每个进程都属于一个进程组（同一组中的进程通常作为命令管道的一部分放在那里，例如cat file | sort | grep 'word'将放置在同一进程组中运行cat(1) ， sort(1)和grep(1)的进程）。 bash是一个类似于任何其他进程的进程，它也属于进程组。 进程组是会话的一部分（会话由一个或多个进程组组成）。 在会话中，最多有一个进程组，称为前台进程组，可能还有许多后台进程组。 前台进程组控制终端（如果有一个连接到会话的控制终端）; 会话负责人（bash）使用tcsetpgrp(3)将进程从后台移动到前台，从前台移动到后台。 发送到进程组的信号将传递到该组中的每个进程。

如果过程组和工作控制的概念对您来说是全新的，我认为您需要阅读以完全理解这个答案。 学习这个的一个很好的资源是UNIX环境 （第3版） 中高级编程的第9章。

话虽这么说，让我们看看这里发生了什么。 我们必须将拼图的每一部分组合在一起。

在这两种情况下，ssh远程端都使用-c调用bash(1) 。 -c标志使bash(1)作为非交互式shell运行。 从联机帮助页：

交互式shell是在没有非选项参数的情况下启动的，没有-c选项，其标准输入和错误都连接到终端（由isatty（3）确定），或者以-i选项开头。 如果bash是交互式的，则设置PS1和$ - 包括i，允许shell脚本或启动文件测试此状态。

此外，重要的是要知道在非交互模式下启动bash时禁用作业控制 。 这意味着bash不会创建一个单独的进程组来运行该命令，因为禁用了作业控制，不需要在前台和后台之间移动此命令，因此它可能只是保留在与bash相同的进程组中。 无论是否使用-t强制在ssh上进行PTY分配，都会发生这种情况。

但是，使用&具有导致shell不等待命令终止的副作用（即使禁用了作业控制）。 从联机帮助页：

如果命令由控制操作符＆终止，则shell在子shell中在后台执行命令。 shell不等待命令完成，返回状态为0.命令由a分隔; 按顺序执行; shell等待每个命令依次终止。 返回状态是最后执行的命令的退出状态。

因此，在这两种情况下，bash都不会等待命令执行，而touch(1)将在与bash(1)相同的进程组中执行。

现在，考虑会话领导者退出时会发生什么。 引自setpgid(2)联机帮助页：

如果会话具有控制终端，并且未设置该终端的CLOCAL标志，并且发生终端挂断，则向会话负责人发送SIGHUP。 如果会话领导者退出，则SIGHUP信号也将被发送到控制终端的前台进程组中的每个进程 。

（强调我的）

当你不使用-t

如果不使用-t ，则远程端没有PTY分配，因此bash不是会话负责人，实际上没有创建新会话。 因为sshd作为守护进程运行，所以分叉+ exec（）的bash进程将没有控制终端。 因此，即使shell很快终止（可能在touch(1)之前），也没有向进程组发送SIGHUP ，因为bash不是会话领导者（并且没有控制终端）。 一切正常。

当你使用-t

-t强制PTY分配，这意味着ssh远程端将调用setsid(2) ，用forkpty(3)分配伪终端+ fork一个新进程，将PTY主设备输入和输出连接到引导的套接字端点到你的机器，最后执行bash(1) 。 forkpty(3)在forked进程中打开PTY slave端，这将成为bash; 由于当前会话没有控制终端，并且正在打开终端设备，因此PTY设备成为会话的控制终端，bash成为会话负责人。

然后同样的事情再次发生： touch(1)在同一个进程组等中执行，yadda yadda。 问题的关键是， 这个时候， 有一个会议领导和控制终端 。 因此，由于bash不会因为&而烦恼，当它退出时， SIGHUP被传递给进程组并touch(1)过早死亡。

关于nohup

nohup(1)在这里不起作用，因为仍然存在竞争条件。 如果bash(1)在nohup(1)有机会设置必要的信号处理和文件重定向之前终止，它将没有效果（这可能发生了什么）

可能的解决办法

强制重新启用作业控制可以修复它。 在bash中，您可以使用set -m执行此操作。 这有效：

ssh -t localhost 'set -m ; touch foobar &'

或者强制bash等待touch(1)完成：

ssh -t localhost 'touch foobar & wait `pgrep touch`'

Answer 2

@Filipe Gonçalves 的回答很好，但有一些问题。 我没有足够的声誉在那里发表评论，所以我在这里更正/丰富内容：

当你不使用 -t 时，

@Filipe 说：

不使用 -t 时，远程端没有 PTY 分配，因此 bash 不是会话领导者，实际上并没有创建新会话。 ...

实际上，bash 是会话领导者，并创建了新会话。

让我们测试一下：

# run sleep background process first, then call ps directly:
[root@90fb1c3f30ce ~]# ssh localhost  'sleep 66 & ps -o pid,ppid,pgid,sess,tpgid,tty,args'
    PID    PPID    PGID    SESS   TPGID TT       COMMAND
 184074      67  184074  184074      -1 ?        sshd: root@notty
 184076  184074  184076  184076      -1 ?        bash -c sleep 66 & ps -o pid,ppid,pgid,sess,tpgid,tty,args
 184081  184076  184076  184076      -1 ?        sleep 66
 184082  184076  184076  184076      -1 ?        ps -o pid,ppid,pgid,sess,tpgid,tty,args

Notice           ^^^^^   ^^^^^

我们可以看到这些 bash/sleep/ps 进程具有相同的PGID/SESS ，等于 bash 进程的 PID 184076 ，但是 sshd parent prcoess 具有不同的 PGID/SESS。 在这里， bash 进程是新会话的领导者，而 bash/sleep/ps 进程属于另一个进程组。

另外，我们可以发现ssh命令并没有立即返回，它仍然等待大约66秒。 你可以在这里找到它的原因：让 ssh 在目标机器的后台执行命令

在 ssh 命令等待期间，我们可以打开另一个会话并运行：

[root@90fb1c3f30ce ~]# ps -eo pid,ppid,pgid,sess,tpgid,tty,args
    PID    PPID    PGID    SESS   TPGID TT       COMMAND
    # unrelated lines removed #
 184074      67  184074  184074      -1 ?        sshd: root@notty
 184081       1  184076  184076      -1 ?        sleep 66
Notice           ^^^^^   ^^^^^

[root@90fb1c3f30ce ~]# ps -e | grep 184076
[root@90fb1c3f30ce ~]#

我们可以看到bash进程（pid 184076）已经消失了，但是sleep后台进程的PGID/SESS没有变化。 没关系， APUE session 9.4：

每个进程组可以有一个进程组组长。 领导者通过其进程组 ID 与其进程 ID 相同来标识。

进程组领导可以创建进程组，在组中创建进程，然后终止。 进程组仍然存在，只要组内至少有一个进程，不管组长是否终止。

那么，为什么这个睡眠过程没有消亡呢？

当你不使用-t时，远程端没有PTY分配，所以远程端的进程组不是前台进程组（没有终端，没有前台或后台的意思）。 因此，即使 shell 很快终止，也不会向其进程组发送 SIGHUP，因为该进程组不是前台进程组。 （SIGHUP 信号将发送到控制终端前台进程组中的每个进程）。

Answer 3

关键是将子进程的stdin / stdout / stderr流与发起的bash / ssh会话分离; 然后不再需要伪tty分配（ ssh -t ）来允许子节点在ssh连接终止时存活。 在这里查看完整的答案......