问SIGINT与其他终端信号如SIGTERM、SIGQUIT和SIGKILL的关系如何？

EN

在POSIX系统上，终止信号通常有以下顺序(根据许多手册页和POSIX规范)：

1. SIGTERM -礼貌地要求进程终止。它应该优雅地终止，清理所有资源(文件、套接字、子进程等)，删除临时文件等等。
2. SIGQUIT -更有力的请求。它将终止不光彩的、仍在清理绝对需要清理的资源，但可能不会删除临时文件，可能会在某个地方写入调试信息；在某些系统上也会编写一个核心转储(不管应用程序是否捕捉到信号)。
3. SIGKILL -最有力的请求。这个过程甚至没有被要求做任何事情，但是系统会清理这个过程，不管它喜欢与否。最有可能的情况是编写核心转储。

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

更新：

到目前为止，我发现的终止信号的最好描述是在GNU LibC文档中。它很好地解释了SIGTERM和SIGQUIT之间有一个意料之中的区别。

上面说的是SIGTERM

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

上面写的是SIGQUIT

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

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

但是，除了CRTL+C发送的SIGINT之外，在此页面上没有其他有用的解释。是否有理由以不同于SIGTERM的方式处理SIGINT？如果是这样的话，这是甚麽原因，处理方式又有何不同呢？