如果同一个 shell 启动了多个连接，则在后台运行的 SSH 连接不会退出

Question 1

前台进程和终端访问控制

要了解发生了什么，您需要了解一些有关共享终端的知识。当两个程序尝试同时从同一个终端读取时会发生什么？每个输入字节随机进入其中一个程序。（不是随机的，如内核中使用 RNG 来决定，只是随机的，因为在实践中不可预测。）当两个程序从管道或任何其他文件类型（从一个位置移动字节流）读取时，会发生同样的情况到另一个（套接字、字符设备等），而不是任何字节都可以多次读取的字节数组（常规文件、块设备）。例如，在终端中运行 shell，找出终端的名称并运行cat。

$ tty
/dev/pts/18
$ cat

然后从另一个终端运行cat /dev/pts/18.现在在终端中输入，并观察线路有时会转到其中一个cat进程，有时会转到另一个进程。当终端处于烘焙模式时，线路将作为一个整体进行调度。如果将终端置于原始模式，则每个字节将独立分派。

那很乱。当然应该有一种机制来决定一个程序获得终端，而其他程序则不获得。嗯，有！它在典型情况下触发，但在我上面设置的场景中不会触发。这种情况很不寻常，因为cat /dev/pts/18不是从开始的/dev/pts/18。从不是在终端内启动的程序访问终端是不常见的。在通常情况下，您在终端中运行 shell，然后从该 shell 运行程序。那么规则就是前台的程序获得终端，后台的程序则得不到。这被称为终端访问控制。它的工作方式是：

每个进程都有一个控制终端（或者没有，通常是因为它没有任何作为终端的打开文件描述符）。
当进程尝试访问其控制终端时，如果该进程不在前台，则内核会阻止它。（有条件限制。对其他航站楼的访问不受限制。）
shell 决定谁是前台进程。（实际上是前台进程组。）它调用tcsetpgrp让内核知道谁应该在前台。

这在典型情况下有效。在 shell 中运行一个程序，该程序将成为前台进程。在后台运行程序（使用&），并且该程序不会在前台运行。当 shell 显示提示时，shell 将自己置于前台。当您使用恢复暂停的作业时fg，该作业将位于前台。与bg，则不然。

如果后台进程尝试从终端读取数据，内核会向其发送 SIGTTIN 信号。该信号的默认操作是挂起进程（如 SIGSTOP）。进程的父进程可以通过调用来了解这一点waitpid与WSTOPPED旗帜；当子进程收到挂起它的信号时，waitpid父进程中的调用将返回并让父进程知道该信号是什么。这就是 shell 知道打印“Stopped (tty input)”的方式。它告诉您的是，该作业由于 SIGTTIN 而被暂停。

由于进程被挂起，所以在它被恢复或杀死之前不会发生任何事情（带有进程未捕获的信号，因为如果进程设置了信号处理程序，则由于进程被挂起，它不会运行）。您可以通过向进程发送 SIGCONT 来恢复该进程，但如果进程正在从终端读取数据，则不会实现任何效果，它将立即收到另一个 SIGTTIN。如果您使用恢复该进程fg，它将转到前台，因此读取会成功。

cat现在您了解了在后台运行时会发生什么：

$ cat &
$ 
[1] + Stopped (tty input)        cat
$

SSH 的案例

现在让我们用 SSH 做同样的事情。

$ ssh localhost sleep 999999 &
$ 
$ 
$ 
[1] + Stopped (tty input)        ssh localhost sleep 999999
$

按Enter有时会转到 shell（位于前台），有时会转到 SSH 进程（此时它会被 SIGTTIN 停止）。为什么？如果ssh从终端读取，它应该立即收到 SIGTTIN，如果不是，那么为什么它会收到 SIGTTIN？

发生的情况是 SSH 进程调用select系统调用以了解其感兴趣的任何文件的输入何时可用（或者输出文件是否准备好接收更多数据）。输入源至少包括终端和网络插座。与不同的是read，select不禁止后台进程，并且ssh在调用时不会收到 SIGTTIN select。目的select是在不破坏任何内容的情况下查明数据是否可用。理想情况select下根本不会改变系统状态，但事实上这并不完全正确。当select告诉 SSH 进程输入在终端文件描述符上可用时，如果进程read随后调用，内核必须承诺发送输入。（如果没有，并且进程调用了read，那么此时可能没有可用的输入，因此返回值select将是一个谎言。）因此，如果内核决定将某些输入路由到 SSH 进程，它会由系统调用返回时决定select。然后 SSH 调用read，此时内核发现后台进程尝试从终端读取数据，并使用 SIGTTIN 暂停它。

请注意，您不需要启动与同一服务器的多个连接。一个就够了。多个连接只会增加出现问题的可能性。

解决方案：不要从终端读取

如果您需要 SSH 会话从终端读取数据，请在前台运行它。

如果您不需要 SSH 会话从终端读取数据，请确保其输入不是来自终端。有两种方法可以做到这一点：

您可以重定向输入：
```
ssh … </dev/null
```
-n您可以使用或指示 SSH 不转发终端连接-f。（-n相当于</dev/null;-f允许 SSH 本身从终端读取，例如读取密码，但命令本身不会打开终端。）
```
ssh -n …
```

请注意，终端和 SSH 之间的断开必须发生在客户端。服务器上运行的进程sleep永远不会从终端读取数据，但 SSH 无法知道这一点。如果客户端接收到标准输入上的输入，它必须将其转发到服务器，这将使数据在缓冲区中可用，以防应用程序决定读取它（并且如果应用程序调用select，它将被告知数据是可用的）。

Answer

前台进程和终端访问控制

要了解发生了什么，您需要了解一些有关共享终端的知识。当两个程序尝试同时从同一个终端读取时会发生什么？每个输入字节随机进入其中一个程序。（不是随机的，如内核中使用 RNG 来决定，只是随机的，因为在实践中不可预测。）当两个程序从管道或任何其他文件类型（从一个位置移动字节流）读取时，会发生同样的情况到另一个（套接字、字符设备等），而不是任何字节都可以多次读取的字节数组（常规文件、块设备）。例如，在终端中运行 shell，找出终端的名称并运行cat。

$ tty
/dev/pts/18
$ cat

然后从另一个终端运行cat /dev/pts/18.现在在终端中输入，并观察线路有时会转到其中一个cat进程，有时会转到另一个进程。当终端处于烘焙模式时，线路将作为一个整体进行调度。如果将终端置于原始模式，则每个字节将独立分派。

那很乱。当然应该有一种机制来决定一个程序获得终端，而其他程序则不获得。嗯，有！它在典型情况下触发，但在我上面设置的场景中不会触发。这种情况很不寻常，因为cat /dev/pts/18不是从开始的/dev/pts/18。从不是在终端内启动的程序访问终端是不常见的。在通常情况下，您在终端中运行 shell，然后从该 shell 运行程序。那么规则就是前台的程序获得终端，后台的程序则得不到。这被称为终端访问控制。它的工作方式是：

每个进程都有一个控制终端（或者没有，通常是因为它没有任何作为终端的打开文件描述符）。
当进程尝试访问其控制终端时，如果该进程不在前台，则内核会阻止它。（有条件限制。对其他航站楼的访问不受限制。）
shell 决定谁是前台进程。（实际上是前台进程组。）它调用tcsetpgrp让内核知道谁应该在前台。

这在典型情况下有效。在 shell 中运行一个程序，该程序将成为前台进程。在后台运行程序（使用&），并且该程序不会在前台运行。当 shell 显示提示时，shell 将自己置于前台。当您使用恢复暂停的作业时fg，该作业将位于前台。与bg，则不然。

如果后台进程尝试从终端读取数据，内核会向其发送 SIGTTIN 信号。该信号的默认操作是挂起进程（如 SIGSTOP）。进程的父进程可以通过调用来了解这一点waitpid与WSTOPPED旗帜；当子进程收到挂起它的信号时，waitpid父进程中的调用将返回并让父进程知道该信号是什么。这就是 shell 知道打印“Stopped (tty input)”的方式。它告诉您的是，该作业由于 SIGTTIN 而被暂停。

由于进程被挂起，所以在它被恢复或杀死之前不会发生任何事情（带有进程未捕获的信号，因为如果进程设置了信号处理程序，则由于进程被挂起，它不会运行）。您可以通过向进程发送 SIGCONT 来恢复该进程，但如果进程正在从终端读取数据，则不会实现任何效果，它将立即收到另一个 SIGTTIN。如果您使用恢复该进程fg，它将转到前台，因此读取会成功。

cat现在您了解了在后台运行时会发生什么：

$ cat &
$ 
[1] + Stopped (tty input)        cat
$

SSH 的案例

现在让我们用 SSH 做同样的事情。

$ ssh localhost sleep 999999 &
$ 
$ 
$ 
[1] + Stopped (tty input)        ssh localhost sleep 999999
$

按Enter有时会转到 shell（位于前台），有时会转到 SSH 进程（此时它会被 SIGTTIN 停止）。为什么？如果ssh从终端读取，它应该立即收到 SIGTTIN，如果不是，那么为什么它会收到 SIGTTIN？

发生的情况是 SSH 进程调用select系统调用以了解其感兴趣的任何文件的输入何时可用（或者输出文件是否准备好接收更多数据）。输入源至少包括终端和网络插座。与不同的是read，select不禁止后台进程，并且ssh在调用时不会收到 SIGTTIN select。目的select是在不破坏任何内容的情况下查明数据是否可用。理想情况select下根本不会改变系统状态，但事实上这并不完全正确。当select告诉 SSH 进程输入在终端文件描述符上可用时，如果进程read随后调用，内核必须承诺发送输入。（如果没有，并且进程调用了read，那么此时可能没有可用的输入，因此返回值select将是一个谎言。）因此，如果内核决定将某些输入路由到 SSH 进程，它会由系统调用返回时决定select。然后 SSH 调用read，此时内核发现后台进程尝试从终端读取数据，并使用 SIGTTIN 暂停它。

请注意，您不需要启动与同一服务器的多个连接。一个就够了。多个连接只会增加出现问题的可能性。

解决方案：不要从终端读取

如果您需要 SSH 会话从终端读取数据，请在前台运行它。

如果您不需要 SSH 会话从终端读取数据，请确保其输入不是来自终端。有两种方法可以做到这一点：

您可以重定向输入：
```
ssh … </dev/null
```
-n您可以使用或指示 SSH 不转发终端连接-f。（-n相当于</dev/null;-f允许 SSH 本身从终端读取，例如读取密码，但命令本身不会打开终端。）
```
ssh -n …
```

请注意，终端和 SSH 之间的断开必须发生在客户端。服务器上运行的进程sleep永远不会从终端读取数据，但 SSH 无法知道这一点。如果客户端接收到标准输入上的输入，它必须将其转发到服务器，这将使数据在缓冲区中可用，以防应用程序决定读取它（并且如果应用程序调用select，它将被告知数据是可用的）。

Question 2

您可以在手册页中找到帮助：

 -n      Redirects stdin from /dev/null (actually, prevents reading from stdin).  This must be used when ssh is run in the
         background.  A common trick is to use this to run X11 programs on a remote machine.  For example, ssh -n
         shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically
         forwarded over an encrypted channel.  The ssh program will be put in the background.  (This does not work if ssh
         needs to ask for a password or passphrase; see also the -f option.)

如果这仍然没有帮助，我会尝试-T（禁用伪 tty 分配），只是一时兴起。

Answer

您可以在手册页中找到帮助：

 -n      Redirects stdin from /dev/null (actually, prevents reading from stdin).  This must be used when ssh is run in the
         background.  A common trick is to use this to run X11 programs on a remote machine.  For example, ssh -n
         shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically
         forwarded over an encrypted channel.  The ssh program will be put in the background.  (This does not work if ssh
         needs to ask for a password or passphrase; see also the -f option.)

如果这仍然没有帮助，我会尝试-T（禁用伪 tty 分配），只是一时兴起。

Question 3

显然，如果同一个 shell 启动到同一服务器的多个 ssh 连接，它们在执行给定的命令后不会返回，而是永远挂起（已停止（tty 输入））。

这是并发访问 TTY 的常见行为。整个进程已经在后台运行，当它尝试写入输出时，不允许访问 TTY 并收到信号 ( SIGTTOU)，该信号未被bash进程捕获，因此执行默认操作 ( Stop)。

该-n选项的解释如下其他答案或者将 IO 重定向到某些文件会对您有所帮助。不确定是否还有更多内容需要描述，但如果有，请澄清。

Answer

显然，如果同一个 shell 启动到同一服务器的多个 ssh 连接，它们在执行给定的命令后不会返回，而是永远挂起（已停止（tty 输入））。

这是并发访问 TTY 的常见行为。整个进程已经在后台运行，当它尝试写入输出时，不允许访问 TTY 并收到信号 ( SIGTTOU)，该信号未被bash进程捕获，因此执行默认操作 ( Stop)。

该-n选项的解释如下其他答案或者将 IO 重定向到某些文件会对您有所帮助。不确定是否还有更多内容需要描述，但如果有，请澄清。

如果同一个 shell 启动了多个连接，则在后台运行的 SSH 连接不会退出

细节

答案1

前台进程和终端访问控制

SSH 的案例

解决方案：不要从终端读取

答案2

答案3

相关内容