☰

SIGHUP 奇怪的行为

tag-icon • tag-icon bash ubuntu process signals
SIGHUP 奇怪的行为

语境：

bash我正在运行一个没有任何重定向的进程，&例如./foo。该进程正在运行while(1)，即它永远运行。此外，该进程会忽略SIGHUP，即在获取它时不会终止。

当我发送SIGHUP到bash进程时，它也会发送 aSIGHUP到我的进程。反过来，我的进程只是记录信号并继续执行其工作。

我的理解：

SIGHUP我从答案中建立了我的理解这里。我的理解是，就我而言，bash进程应该被阻止而不是终止。

问题：

但事实并非如此。bash当我的进程继续时，进程确实终止。但现在，不再是bash进程，而是/lib/systemd/systemd --user成为新的父级。

环境及其他细节：

Linux lap-0117 5.4.0-87-generic #98~18.04.1-Ubuntu SMP Wed Sep 22 10:45:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

答案1

这是正常的。

shell 终止，因为当控制终端消失时，SIGHUP 通常会发送到 shell（即，这是一个资源撤销接口，Unix 中为数不多的接口之一），并且没有终端的 shell 是毫无意义的。

shell 本身处理 SIGHUP，并且信号处理程序将 SIGHUP 转发到所有后台进程，以便它们也被告知控制终端已消失。任何离开默认处理程序的进程都将在此处终止，通常这些是需要终端的 shell 命令。

例如，当您用于tail -f查看日志文件然后关闭终端窗口时，此机制会进行清理。 shell 和tail在其中运行的命令都变得毫无用处，因为它们没有可以交互的终端，因此它们也被终止。

通常，“孤立”进程附加到 PID 1，因为这是唯一可以在任何时候处理 SIGCHLD 并收集子进程的退出代码的进程。据推测，systemd 在这里做了一些有趣的事情，将其附加到 systemd 的用户实例，这也履行了这个合同。

相关内容