SIGHUP奇怪行为

Question

上下文：

我从bash运行一个进程，没有&，也没有任何重定向，比如./foo。该进程正在运行while(1)，即它将永远运行。此外，该进程忽略了SIGHUP，即当它得到它时不终止。

当我将SIGHUP发送到bash进程时，它也会向我的进程发送一个SIGHUP。我的过程，反过来，只是记录信号，并继续它的工作。

My理解：

我对SIGHUP的理解是从这里的答案中建立起来的。我所理解的是，在我的例子中，bash进程应该被阻塞而不是终止。

问题：

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

Environment和其他细节：

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

Answer 1

这是正常的。

外壳终止，因为当控制终端离开时，SIGHUP通常被发送到shell (即资源撤销接口，我们在Unix中仅有的几个接口之一)，而没有终端的shell没有意义。

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

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

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