SIGINT 与其他终止信号（如 SIGTERM、SIGQUIT 和 SIGKILL）有何关系？-IT科技

摘要：问题描述：在 POSIX 系统上，终止信号通常具有以下顺序（根据许多 MAN 页面和 POSIX 规范）：SIGTERM - 礼貌地要求进程终止。它将正常终止，清理所有资源（文件、套接字、子进程等）、删除临时文件等。SIGQUIT - 更强有力的请求。它将非正常终止，仍然清理绝对需要清理的资源，但可能不会删除...

问题描述：

在 POSIX 系统上，终止信号通常具有以下顺序（根据许多 MAN 页面和 POSIX 规范）：

SIGTERM - 礼貌地要求进程终止。它将正常终止，清理所有资源（文件、套接字、子进程等）、删除临时文件等。
SIGQUIT - 更强有力的请求。它将非正常终止，仍然清理绝对需要清理的资源，但可能不会删除临时文件，可能会在某处写入调试信息；在某些系统上，还会写入核心转储（无论应用程序是否捕获该信号）。
SIGKILL - 最强烈的请求。甚至不要求进程执行任何操作，但系统将清理进程，无论它是否喜欢。最有可能写入核心转储。

如何融入该图？CLI 进程通常在用户点击时SIGINT终止，但是后台进程也可以通过使用实用程序终止。我在规范或头文件中看不到的是，是否比更有力或更弱，或者和之间是否有任何差异。SIGINT`CRTL+CSIGINTKILLSIGINTSIGTERMSIGINTSIGTERM`

更新：

到目前为止，我发现的有关终止信号的最佳描述是在GNU LibC 文档中。它很好地解释了 SIGTERM 和 SIGQUIT 之间存在的预期差异。

其中提到SIGTERM：

这是礼貌地要求程序终止的正常方式。

其中提到SIGQUIT：

[...] 并在终止进程时生成核心转储，就像程序错误信号一样。您可以将其视为用户“检测到”的程序错误情况。 [...] 在处理 SIGQUIT 时最好省略某些类型的清理。例如，如果程序创建了临时文件，它应该通过删除临时文件来处理其他终止请求。但 SIGQUIT 最好不要删除它们，以便用户可以结合核心转储检查它们。

并且SIGHUP解释得也足够清楚。SIGHUP 并不是真正的终止信号，它只是意味着与用户的“连接”已丢失，因此应用程序不能期望用户读取任何进一步的输出（例如 stdout/stderr 输出），并且不再需要用户输入。对于大多数应用程序来说，这意味着它们最好退出。理论上，应用程序还可以决定在收到 SIGHUP 时进入守护进程模式，现在作为后台进程运行，将输出写入配置的日志文件。对于大多数已经在后台运行的守护进程，SIGHUP 通常意味着它们应重新检查其配置文件，因此您可以在编辑配置文件后将其发送到后台进程。

但是，此页面上没有对 SIGINT 的有用解释，除了它是由 CRTL+C 发送的。是否有任何理由SIGINT以不同于的方式处理SIGTERM？如果是，原因是什么，处理方式有何不同？

解决方案 1：

SIGTERM并且SIGKILL用于通用的“终止该进程”请求。 SIGTERM（默认情况下）并且SIGKILL（总是）将导致进程终止。 SIGTERM可能会被进程捕获（例如，以便它可以根据需要进行自己的清理），甚至完全忽略；但SIGKILL不能被捕获或忽略。

SIGINT和SIGQUIT专门用于来自终端的请求：可以指定特定的输入字符来生成这些信号（取决于终端控制设置）。的默认操作与的默认操作和的不可更改操作SIGINT是同一类型的进程终止；的默认操作也是进程终止，但可能会发生其他实现定义的操作，例如生成核心转储。如果需要，进程可以捕获或忽略它们。SIGTERM`SIGKILL`SIGQUIT

SIGHUP正如您所说，旨在指示终端连接已丢失，而不是终止信号。但是，同样，的默认操作（如果进程未捕获或忽略它）是以与等SIGHUP相同的方式终止进程。SIGTERM

POSIX定义中有一个表signal.h，列出了各种信号及其默认操作和用途，而通用终端接口章节包含有关终端相关信号的更多详细信息。

解决方案 2：

man 7 signal

这是Linux 手册页项目的便捷非规范手册页，您经常需要查看它来了解 Linux 信号信息。

3.22 版本提到了一些有趣的事情，例如：

SIGKILL 和 SIGSTOP 信号不能被捕获、阻止或忽略。

并包含表格：

Signal     Value     Action   Comment
----------------------------------------------------------------------
SIGHUP        1       Term    Hangup detected on controlling terminal
                              or death of controlling process
SIGINT        2       Term    Interrupt from keyboard
SIGQUIT       3       Core    Quit from keyboard
SIGILL        4       Core    Illegal Instruction
SIGABRT       6       Core    Abort signal from abort(3)
SIGFPE        8       Core    Floating point exception
SIGKILL       9       Term    Kill signal
SIGSEGV      11       Core    Invalid memory reference
SIGPIPE      13       Term    Broken pipe: write to pipe with no
                              readers
SIGALRM      14       Term    Timer signal from alarm(2)
SIGTERM      15       Term    Termination signal
SIGUSR1   30,10,16    Term    User-defined signal 1
SIGUSR2   31,12,17    Term    User-defined signal 2
SIGCHLD   20,17,18    Ign     Child stopped or terminated
SIGCONT   19,18,25    Cont    Continue if stopped
SIGSTOP   17,19,23    Stop    Stop process
SIGTSTP   18,20,24    Stop    Stop typed at tty
SIGTTIN   21,21,26    Stop    tty input for background process
SIGTTOU   22,22,27    Stop    tty output for background process

它总结了Action区分 SIGQUIT 和 SIGINT 的信号，因为 SIGQUIT 具有动作Core和 SIGINT Term。

这些操作记录在同一文档中：

The entries in the &quot;Action&quot; column of the tables below specify the default disposition for each signal, as follows:

Term   Default action is to terminate the process.

Ign    Default action is to ignore the signal.
Core   Default action is to terminate the process and dump core (see core(5)).
Stop   Default action is to stop the process.
Cont   Default action is to continue the process if it is currently stopped.

从内核的角度来看，我看不出 SIGTERM 和 SIGINT 有什么区别，因为两者都有动作Term，都可以被捕获。这似乎只是一种“常用惯例区别”：

SIGINT 是当您从终端按 CTRL-C 时发生的
SIGTERM 是kill

有些信号是 ANSI C 的，有些不是

一个相当大的区别是：

SIGINT 和 SIGTERM 是 ANSI C，因此更易于移植
SIGQUIT 和 SIGKILL 不是

它们在C99 草案 N1256的“7.14 信号处理 <signal.h>”部分中有描述：

SIGINT 收到交互式注意信号
SIGTERM 向程序发送终止请求，例如当你想关闭计算机时，操作系统会首先尝试终止程序，以便它们有机会保存任何未保存的工作

这使得 SIGINT 成为交互式 Ctrl + C 的良好候选者。

POSIX 7

POSIX 7 使用标题记录信号signal.h：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

该页面还有以下有趣的表格，其中提到了我们已经看到的一些内容man 7 signal：

Signal    Default Action   Description
SIGABRT   A                Process abort signal.
SIGALRM   T                Alarm clock.
SIGBUS    A                Access to an undefined portion of a memory object.
SIGCHLD   I                Child process terminated, stopped,
SIGCONT   C                Continue executing, if stopped.
SIGFPE    A                Erroneous arithmetic operation.
SIGHUP    T                Hangup.
SIGILL    A                Illegal instruction.
SIGINT    T                Terminal interrupt signal.
SIGKILL   T                Kill (cannot be caught or ignored).
SIGPIPE   T                Write on a pipe with no one to read it.
SIGQUIT   A                Terminal quit signal.
SIGSEGV   A                Invalid memory reference.
SIGSTOP   S                Stop executing (cannot be caught or ignored).
SIGTERM   T                Termination signal.
SIGTSTP   S                Terminal stop signal.
SIGTTIN   S                Background process attempting read.
SIGTTOU   S                Background process attempting write.
SIGUSR1   T                User-defined signal 1.
SIGUSR2   T                User-defined signal 2.
SIGTRAP   A                Trace/breakpoint trap.
SIGURG    I                High bandwidth data is available at a socket.
SIGXCPU   A                CPU time limit exceeded.
SIGXFSZ   A                File size limit exceeded.

BusyBox 初始化

BusyBox 1.29.2 的默认reboot命令会向进程发送 SIGTERM，休眠一秒钟，然后发送 SIGKILL。这似乎是不同发行版之间的通用惯例。

当您使用以下命令关闭 BusyBox 系统时：

reboot

它向 init 进程发送信号。

然后，init 信号处理程序最终调用：

static void run_shutdown_and_kill_processes(void)
{
    /* Run everything to be run at &quot;shutdown&quot;.  This is done _prior_
     * to killing everything, in case people wish to use scripts to
     * shut things down gracefully... */
    run_actions(SHUTDOWN);

    message(L_CONSOLE | L_LOG, &quot;The system is going down NOW!&quot;);

    /* Send signals to every process _except_ pid 1 */
    kill(-1, SIGTERM);
    message(L_CONSOLE, &quot;Sent SIG%s to all processes&quot;, &quot;TERM&quot;);
    sync();
    sleep(1);

    kill(-1, SIGKILL);
    message(L_CONSOLE, &quot;Sent SIG%s to all processes&quot;, &quot;KILL&quot;);
    sync();
    /*sleep(1); - callers take care about making a pause */
}

打印到终端：

The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes

这是一个最小的具体例子。

内核发送的信号

信号终止：
- OOM 杀手：Linux 内存管理中的 RSS 和 VSZ 是什么

解决方案 3：

正如 DarkDust 所指出的，许多信号具有相同的结果，但进程可以通过区分每个信号的生成方式来为它们附加不同的操作。查看 FreeBSD 内核源代码 (kern_sig.c)，我发现这两个信号的处理方式相同，它们终止进程并传递给任何线程。

SA_KILL|SA_PROC,             /* SIGINT */
SA_KILL|SA_PROC,             /* SIGTERM */

解决方案 4：

在 Google 上快速搜索sigint 与 sigterm之后，看起来两者之间唯一的区别在于它是由键盘快捷键启动还是通过明确调用来启动kill。

因此，例如，您可以拦截信号并对其进行特殊处理，因为您知道该信号很可能是通过键盘快捷键发送的。也许可以刷新屏幕或执行其他操作，而不是终止程序（不推荐，因为人们希望^C终止程序，这只是一个例子）。

我还了解到^应该发送 sigquit，我自己可能会开始使用它。看起来非常有用。

解决方案 5：

只要您获得许可，您就可以使用kill（系统调用和实用程序）向任何进程发送几乎任何信号。进程无法区分信号是如何产生的以及是谁发送的。

话虽如此，SIGINT实际上是用来发出Ctrl-C中断信号的，而SIGTERM是一般的终端信号。没有信号“更有力”的概念，唯一的例外是有些信号无法被阻止或处理（SIGKILL并且SIGSTOP，根据手册页）。

一个信号只能根据接收进程如何处理信号（以及该信号的默认操作是什么）而比另一个信号“更有力”。例如，默认情况下，SIGTERM和SIGINT都会导致终止。但如果您忽略它SIGTERM，则它不会终止您的进程，但SIGINT仍然会终止。

解决方案 6：

除少数信号外，信号处理程序可以捕获各种信号，或者可以修改收到信号时的默认行为。signal(7)有关详细信息，请参阅手册页。