这个Q& A早于systemd v230 debacle.从systemd v230开始,新的默认设置是终止终止登录会话的所有子节点,无论采取了哪些历史上有效的预防措施来防止这种情况.可以通过在/etc/systemd/logind.conf中设置KillUserProcesses = no来更改行为,或者使用特定于systemd的机制在用户空间中启动守护程序来规避行为.这些机制超出了这个问题的范围.

下面的文本描述了传统上在UNIX设计空间中工作的时间比Linux已经存在的时间长.

他们会被杀死,但不一定立即被杀死.这取决于SSH守护程序确定您的连接已停止所需的时间.以下是一个较长的解释,将帮助您了解它的实际工作原理.

登录时,SSH守护程序为您分配了一个伪终端,并将其附加到用户配置的登录shell.这称为控制终端.你在那个时候正常开始的每一个程序,无论多少层太深,最终都会将它的祖先追溯到那个外壳.您可以使用pstree命令进行观察.

当与您的连接关联的SSH守护进程确定您的连接已死时,它会向登录shell发送挂断信号(SIGHUP).这通知shell你已经消失了它应该开始清理它自己.此时发生的事情是特定于shell(在其文档页面中搜索“HUP”),但在大多数情况下,它将在终止之前开始向与其关联的正在运行的作业发送SIGHUP.反过来,这些过程中的每一个都将执行它们在接收到该信号时配置的任何操作.通常这意味着终止.如果这些工作有自己的工作,信号也会经常传递.

在控制终端挂断后仍然存在的进程要么与自己的终端(你在其中启动的守护程序进程)解除关联,要么使用带有前缀的nohup命令调用的进程. (即“不要挂断”)守护进程以不同的方式解释HUP信号;因为它们没有控制终端并且不自动接收HUP信号,所以它被重新用作管理员的手动请求以重新加载配置.具有讽刺意味的是,这意味着大多数管理员都不会为非守护进程学习这种信号的“挂断”使用,直到很久以后.这就是你读这个的原因！

终端多路复用器是在断开连接之间保持shell环境完整的常用方法.它们允许您以稍后可以重新连接到它们的方式从shell进程中分离,无论该断开是偶然还是故意. tmux和屏幕是比较流行的;使用它们的语法超出了你的问题的范围,但它们值得研究.

有人请求我详细说明SSH守护进程需要多长时间才能确定您的连接已经死亡.这是一种特定于SSH守护程序的每个实现的行为,但是当任何一方重置TCP连接时,您可以指望所有这些行为终止.如果服务器尝试写入套接字并且TCP数据包未被确认,则会很快发生,如果没有尝试写入PTY,则会缓慢发生.

在这个特定的上下文中,最有可能触发写入的因素是：

>尝试写入服务器端PTY的进程(通常是前台进程). (服务器 – >客户端)
>用户尝试在客户端写入PTY. (客户端 – >服务器)
>任何类型的Keepalive.默认情况下,这些通常不是由客户端或服务器启用的,通常有两种风格：应用程序级别和基于TCP的(即SO_KEEPALIVE). Keepalive相当于服务器或客户端不经常向另一端发送数据包,即使没有任何理由可以写入套接字.虽然这通常是为了避免过快地连接超时的防火墙,但它具有额外的副作用,即当另一方没有更快地响应时发送者注意到.

TCP会话的通常规则适用于此：如果客户端和服务器之间的连接中断,但在问题期间双方都没有尝试发送数据包,则连接将继续存在,前提是双方都在事后响应并接收到预期的TCP序号.

如果一方已确定套接字已死,则效果通常是立即的：sshd进程将发送HUP并自行终止(如前所述),或者客户端将通知用户检测到的问题.值得注意的是,仅仅因为一方认为另一方已经死亡并不意味着另一方已被通知此事.连接的孤立端通常将保持打开状态,直到它尝试写入并超时,或从另一端接收TCP重置. (如果此时连接可用)此答案中描述的清理仅在服务器注意到后才会发生.