【问题标题】:Who is the original sender of SIGHUP when the ssh connection is closed?当 ssh 连接关闭时,SIGHUP 的原始发送者是谁?
【发布时间】:2019-03-05 21:50:08
【问题描述】:

我们知道,当 ssh 连接消失时,bash 会收到一个 SIGHUP,并将这个信号转发给它的所有子节点。

我想知道这个 SIGHUP 的原始发送者是谁,是 ssh 客户端、ssh 服务器、操作系统还是其他什么?

我看了openssh-portabal的代码,发现只有这里使用了SIGHUP:https://github.com/openssh/openssh-portable/blob/master/sshconnect.c#L285

调用者似乎是客户端: https://github.com/openssh/openssh-portable/blob/master/ssh.c#L1533

我在服务器端 sshd.c 中没有找到任何发件人代码

这是否意味着发件人是客户?在这种情况下,如果连接中断,服务器将不会收到 SIGHUP。我不太确定这一点,但根据我的经验,这似乎不是真的。

所以我很好奇谁应该是原始发件人。这个有标准吗?

【问题讨论】:

标签: linux ssh linux-kernel tty pty


【解决方案1】:

连接服务器端的 bash 进程正在运行,其控制终端设置为伪终端对的从端,主端连接到 sshd 进程。

当连接终止时,sshd进程关闭伪终端的master端,导致内核伪终端驱动挂起伪终端的slave端。当slave端挂断时,内核tty核心发送SIGHUPSIGCONT信号给终端的会话领导(通常是bash进程)和会话领导进程组中的每个进程。

这并不特定于伪终端和 ssh - 如果您通过连接到串行端口的调制解调器拨入服务器并且调制解调器挂断(这是“挂断”/ SIGHUP 命名起源)。如您所知,这是由来已久的历史行为。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-04-13
    • 2010-10-29
    • 1970-01-01
    • 2014-01-11
    • 1970-01-01
    • 1970-01-01
    • 2013-10-28
    • 1970-01-01
    相关资源
    最近更新 更多