当进程的控制 shell 被杀死时优雅地终止进程

Question

我有一个命令行应用程序。我面临的问题是，有时该应用程序的用户也会使用以下命令直接关闭运行我们的应用程序的终端：

kill -9 pid_of_parent_console

在上述情况下，我们的应用程序应该通过所有必要的清理来优雅地关闭。为此，我编写了一个信号处理程序来处理 SIGHUP 信号，因为当控制进程退出的终端时，它会将 SIGHUP 发送到在其下运行的进程，我们已经处理了这个处理以优雅地退出我们的进程。但问题是如果用户打开一个终端假设是默认 bash，然后他再次在其中键入 bash 命令然后运行我们的应用程序，如果假设在打开终端后杀死应用程序父进程（在打开终端后手动执行 bash，那么我们的应用程序不会获得 SIGHUP 并且不会正常退出。为了简单起见，我已经写了以下代码重现了该问题：

#include <stdio.h>
#include <signal.h>

FILE *fp = NULL;
int flag = 1;

void handler(int signum)
{
    flag = 0;
}

int main()
{
    signal(SIGHUP, handler);
    // just for testing
    fp = fopen("file", "w");

    // loop terminates only when HUP is generated
    while (flag);

    // if SIGHUP is generated then code should reach here
    // and write the below in file.
    fprintf(fp, "SIGHUP Generated");

    fclose(fp);
return 0;    
}

为简单起见，我没有使用 sigaction 来处理信号。

我观察到的是，当我打开终端并按 tty 命令并记下与之关联的标准输入文件的名称时，然后在同一终端中输入 bash 命令时，如果我记下标准输入文件，则再次输入使用 tty 命令与之关联，我发现两个 bash shell，一个在我启动终端时默认打开，另一个是我通过在 bash 控制台中键入 bash 命令手动打开的，共享相同的标准输入文件名。

因此，当我杀死作为我的进程的父进程的第二个 bash 时，与之关联的标准输入文件不会被关闭，我认为这就是我没有收到 SIGHUP 信号的原因。

当它的控制控制台被杀死时，我可以使用任何其他方法来过于优雅地杀死我的进程。

使用的终端模拟器：GNOME Terminal 2.31.3 默认外壳：bash

Answer 1

无论操作系统如何，SIGKILL（即信号-9）都由内核直接处理，并且在任何用户态处理程序有机会处理任何内容之前，进程就被杀死了。 Linux 内核就像 Solaris 内核一样。

那么目标进程就没有办法保护自己免受该信号的影响（除了在发送方或内核中拦截它）。

另一方面，关闭终端仿真器窗口会向其发送 XEvent。在退出之前，终端模拟器可能应该向您的进程发送一个 SIGHUP 信号。

我建议在 Solaris 10 机器上使用 dtrace 来调查这个过程。从这个脚本开始，它显示所有发送的信号：http://www.brendangregg.com/DTrace/kill.d