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文档中
。它很好地说明了SIGTERM和SIGQUIT之间存在预期的差异。

它说关于SIGTERM：

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

关于SIGQUIT，它说：

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

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其中列出了各种信号以及它们的默认操作和目的，“
常规终端接口”一章包括与终端相关的信号的更多详细信息。