linux - SIGINT 与 SIGTERM、SIGQUIT 和 SIGKILL 等其他终止信号有何关系？

Question

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

1. SIGTERM - 礼貌地要求进程终止。它应该优雅地终止，清理所有资源(文件、套接字、子进程等)，删除临时文件等等。

2. SIGQUIT - 更有力的请求。它将不优雅地终止，仍然清理绝对需要清理的资源，但可能不会删除临时文件，可能会在某处写入调试信息；在某些系统上，还会写入核心转储(无论信号是否被应用捕获)。

3. SIGKILL - 最有力的请求。该进程甚至没有被要求做任何事情，但系统会清理该进程，不管它是否喜欢。很可能已写入核心转储。

SIGINT 是如何融入这张图片的？当用户点击 CRTL+C 时，CLI 进程通常由 SIGINT 终止，但是后台进程也可以由 SIGINT 使用 终止>KILL 实用程序。我在规范或头文件中看不到的是，如果 SIGINT 或多或少比 SIGTERM 更有力，或者 SIGINT 之间是否有任何区别和 SIGTERM。

更新:

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

上面写着SIGTERM:

It is the normal way to politely ask a program to terminate.

它说的是SIGQUIT:

[...] and produces a core dump when it terminates the process, just like a program error signal.You can think of this as a program error condition “detected” by the user. [...]Certain kinds of cleanups are best omitted in handling SIGQUIT. For example, if the programcreates temporary files, it should handle the other termination requests by deleting the temporaryfiles. But it is better for SIGQUIT not to delete them, so that the user can examine them inconjunction with the core dump.

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

然而，这个页面上没有关于 SIGINT 的有用解释，除了它是由 CRTL+C 发送的。有什么理由可以以与 SIGTERM 不同的方式处理 SIGINT 吗？如果是这样，这是什么原因，处理方式有何不同？

Answer 1

SIGTERM和 SIGKILL用于一般用途的“终止此进程” 请求。 SIGTERM (默认)和 SIGKILL (总是)会导致进程终止。 SIGTERM可能被进程捕获(例如，如果它愿意，它可以自己进行清理)，甚至完全忽略；但是 SIGKILL不能被捕获或忽略。

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

SIGHUP ，正如您所说，旨在表明终端连接已丢失，而不是作为终止信号。但是，SIGHUP 的默认操作也是如此。 (如果进程没有捕获或忽略它)就是以与SIGTERM相同的方式终止进程等等。

POSIX 中有一个表 signal.h 的定义其中列出了各种信号及其默认操作和目的，以及 General Terminal Interface本章包含有关终端相关信号的更多详细信息。