注销时后台进程是否会收到 SIGHUP？

Question

这是这个问题的后续。

我还进行了一些测试；看起来这是在物理控制台上完成还是通过 SSH 完成并不重要，这也不仅仅发生在 SCP 上；我也用cat /dev/zero > /dev/null. 行为完全相同：

• 在后台使用启动一个进程&（或者在它开始使用后把它放在后台使用CTRL-Zand bg）；这是在不使用nohup.
• 注销。
• 重新登录。
• 进程还在那里，愉快地运行着，现在是init.

如果发送，我可以确认 SCP 和 CAT 都立即退出SIGHUP；我使用kill -HUP.

因此，看起来 SIGHUP 确实不会在注销时发送，至少不会发送到后台进程（由于显而易见的原因，无法使用前台进程进行测试）。

这发生在我最初使用 VMware ESX 3.5（基于 RedHat）的服务控制台时，但我能够在 CentOS 5.4 上完全复制它。

问题再次出现：是否应该在注销时将 SIGHUP 发送到进程，即使它们在后台运行？为什么这没有发生？

---

编辑

strace根据凯尔的回答，我检查了。
正如我所期望的那样，从启动它的 shell 注销时，该进程没有收到任何信号。在使用服务器的控制台和通过 SSH 时都会发生这种情况。

Answer 1

找到了答案。

对于 BASH，这取决于huponexitshell 选项，可以使用内置shopt命令查看和/或设置该选项。

看起来这个选项默认是关闭的，至少在基于 RedHat 的系统上是这样。

BASH 手册页上的更多信息：

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

如果 huponexit shell 选项已使用 shopt 设置，则 bash 会在交互式登录 shell 退出时向所有作业发送 SIGHUP。