总是想知道这一点.
解决方法 编辑2016年:这个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重置. (如果此时连接可用)此答案中描述的清理仅在服务器注意到后才会发生.
总结以上是内存溢出为你收集整理的linux – 从SSH会话断开连接是否会导致程序崩溃?全部内容,希望文章能够帮你解决linux – 从SSH会话断开连接是否会导致程序崩溃?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)