SIGINT与其他终止信号(例如SIGTERM,SIGQUIT和SIGKILL)有何关系?
在POSIX系统上,终止信号通常具有以下顺序(根据许多MAN页和POSIX规范): SIGTERM-礼貌地要求进程终止。它应正常终止,清理所有资源(文件,套接字,子进程等),删除临时文件等。 SIGQUIT-更有力的要求。它会终止不合时宜的情况,仍然清理绝对需要清理的资源,但可能不会删除临时文件,可能会在某些地方写入调试信息;在某些系统上,还将写入核心转储(无论信号是否被应用捕获)。 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?如果是这样,这将是什么原因?处理方式会有什么不同?