如果通过 SSH 连接到服务器后，终端在没有退出命令的情况下关闭，会发生什么情况？

正在运行的进程将收到hup信号。

接下来会发生什么完全取决于开发人员对该程序的投资。它应该默认终止。

要检查的脚本：

#!/bin/bash

trap 'touch hupped; exit' hup

echo $$

while :; do sleep 1; echo -n .; done

首先它打印它的进程号，然后每秒打印一个点到标准输出。收到信号后，hup在当前目录中创建一个文件hupped并退出。

如果终端正确终止，它会发送一个关闭 ssh 连接的命令，然后向所有进程发送一个 hup 信号。如果终端进程被杀死，那么操作系统发送一个tcp-fin数据包，服务器发生异常，然后hup。如果连接被错误地断开，例如网络断开，则 fin 将无法到达，并且该进程将运行一段时间（通常为半小时左右），直到连接被服务器超时。此外，与其他情况一样，hup。

在关闭控制终端时，bash 收到一个 SIGHUP 并退出，[在交互式情况下] 将信号发送到其作业列表中的所有进程。停止的任务也会收到 SIGCONT。来自关于信号的 bash 文档（与使用 创建的进程组的预期行为相匹配setpgid(2)）：

shell 在收到 SIGHUP 后默认退出。在退出之前，交互式 shell 会将 SIGHUP 重新发送到所有正在运行或停止的作业。停止的作业被发送 SIGCONT 以确保它们收到 SIGHUP。为防止 shell 向特定作业发送 SIGHUP 信号，应使用 disown 内置命令将其从作业表中删除（请参阅 Job Control Builtins ）或使用 disown -h 将其标记为不接收 SIGHUP。

nohup允许您忽略 SIGHUP 信号，disown该命令允许您从该列表中排除任务。systemd 版本 230更改了用户会话结束时的默认行为。

客户端上的 ssh 进程收到一个 SIGHUP。ssh 在收到信号时恢复标准输入，如有必要，将信号转发给代理命令（如果有），然后退出。顺便说一句，通常当 bash 正常退出时（exit, Ctrl-D），SIGHUP 不会被发送到任务，因为该huponexit选项默认是关闭的。在哪些情况下，您注销时不会将 SIGHUP 发送到作业？

同时，服务器可能不会立即知道 ssh 客户端已经死亡。与 SSH 会话断开连接会杀死您的程序吗？当服务器上的 sshd 注意到连接已死时，它会在服务器上发送一个 SIGHUP 信号并重复上面引用的行为。