07-SIGHUP信号

34.6　SIGHUP信号

当一个控制进程失去其终端连接之后，内核会向其发送一个SIGHUP信号来通知它这一事实。（还会发送一个SIGCONT信号以确保当该进程之前被一个信号停止时重新开始该进程。）一般来讲，这种情况可能会在下面两个场景中出现。

• 当终端驱动器检测到连接断开后，表明调制解调器或终端行上信号的丢失。
• 当工作站上的终端窗口被关闭时。发生这种情况是因为最近打开的与终端窗口关联的伪终端的主侧的文件描述符被关闭了。

SIGHUP信号的默认处理方式是终止进程。如果控制进程处理了或忽略了这个信号，那么后续尝试从终端中读取数据的请求就会返回文件结束的错误。

SUSv3声称如果终端断开发生的同时还满足调用read()时抛出EIO错误的条件的话，那么调用read()既有可能返回文件结束，也有可能返回EIO错误。可移植的程序必须要处理好这两种情况。在34.7.2节和34.7.4节中将介绍在哪些情况下调用read()会发生EIO错误。

向控制进程发送SIGHUP信号会引起一种链式反应，从而导致将SIGHUP信号发送给很多其他进程。这个过程可能会以下列两种方式发生。

• 控制进程通常是一个shell。shell建立了一个SIGHUP信号的处理器，这样在进程终止之前，它能够将SIGHUP信号发送给由它所创建的各个任务。在默认情况下，这个信号会终止那些任务，但如果它们捕获了这个信号，就能知道shell进程已经终止了。
• 在终止终端的控制进程时，内核会解除会话中所有进程与该控制终端之间的关联关系以及控制终端与该会话的关联关系（因此另一个会话首进程可以请求该终端成为控制终端了），并且通过向该终端的前台进程组的成员发送SIGHUP信号来通知它们控制终端的丢失。

下一节将深入介绍这两种方式的细节信息。

SIGHUP信号也可以用作他用。在34.7.4节中可以看到当一个进程组成为孤儿进程组时会生成SIGHUP信号。此外，手工发送SIGHUP信号通常用来触发daemon进程重新初始化自身或重新读取其配置文件。（根据定义，daemon进程没有控制终端，因此无法从内核接收SIGHUP信号。）37.4节将会介绍如何配合使用SIGHUP信号和daemon进程。