从 ssh 会话运行的程序是否依赖于连接？

Question

从 ssh 会话运行的程序是否依赖于与客户端的连接？例如，当连接真的很慢时。那么它会主动等待直到屏幕上打印出来的东西吗？

如果它确实取决于连接，例如screen或byobu也会发生这种情况吗？因为有了这些，即使在与主机断开连接后，程序也会保持运行。

---

注意：我只找到了这些相关问题：

• 暂时断开 ssh 会话会影响正在运行的程序吗？
• 当连接丢失时，通过 ssh 筛选会话会发生什么？

Answer 1

程序的输出是缓冲的，所以如果连接很慢，如果缓冲区填满，程序将停止。

如果您使用screen，它还有一个缓冲区，用于尝试显示到连接的会话。但是如果不能足够快地更新远程终端，屏幕会话中连接的程序将不会停止screen。就像当连接丢失时，程序会继续填充screens缓冲区直到溢出（推出最旧的信息）。您看到的（并且可以回滚到）取决于该缓冲区中（仍然）的内容。screen有效地将您的程序与您的终端（以及您的慢速 SSH 连接）分离。

Answer 2

如果底层 TCP 连接收到带有RST的数据包，则 SSH 连接可能会过早终止标志。如果一方发送了一个数据包（这可能是一个定期的 SSH keepalive 探测）但没有在合理的时间内收到 TCP 确认，或者如果路由器确定连接空闲时间过长，或者如果ISP 只是在作恶。

在Unix终端模型中，当终端连接断开时，终端驱动发送HUP信号外壳，外壳的终止也会导致向外壳中运行的进程发送 SIGHUP。

来自Unix Programmer FAQ，第 1.15 项：

SIGHUP是一个信号，按照惯例，“终端线路挂了”。它与父进程无关，通常由 tty 驱动程序生成（并交付给前台进程组）。

然而，作为会话管理系统的一部分，有两种情况在SIGHUP进程死亡时发送：

• 当终止的SIGHUP进程是连接到终端设备的会话的会话领导者时，将被发送到该终端设备的前台进程组中的所有进程。

• 当一个进程的死亡导致一个进程组成为孤立的，并且孤立组中的一个或多个进程被停止时，然后 SIGHUP和SIGCONT被发送到孤立组的所有成员。（孤立进程组是指组中没有进程的父进程属于同一个会话，但不属于同一个进程组的进程组。）

SIGHUP的默认信号处理程序是终止进程：

Signal     Value     Action   Comment
----------------------------------------------------------------------
SIGHUP        1       Term    Hangup detected on controlling terminal
                              or death of controlling process

但是，可以避免进程终止。

• 您可以插入一个忽略 SIGHUP 的信号处理程序。要以用户身份执行此操作，请将命令包装在nohup. 例如：

  nohup make all &
  

• 您可以告诉 shell 将子进程与其分离。例如，Bash 有一个disown内置命令：

  make all
  

  CtrlZ

  bg
  disown %1
  

  然后，SIGHUP 将不会传播给孩子（不再是孩子）。

• 某些程序，特别是daemons，将自动使用上述机制：程序可以安装备用 SIGHUP 处理程序（使用sigaction(2)），或者它可以选择加入新会话（setsid(2)）。
• 您可以运行screen或tmux，它会分配一个伪 TTY 来运行一个带有 shell 的会话，该会话在 SSH 连接中断时不会收到 SIGHUP。SIGHUP 不会从 SSH 会话中继到 screen/tmux 会话。

顺便说一句，处理不可靠 SSH 连接的另一种方法是改用Mosh协议。Mosh 运行在 UDP 之上，因此没有 TCP 连接可能被重置。