在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？如果是这样，这将是什么原因？处理方式会有什么不同？