在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通常意味着他们将重新检查其配置文件,因此您在编辑配置文件后将其发送到后台进程.
但是,除了CRTL + C发送的SIGINT之外,此页面上没有有用的SIGINT解释.是否有理由以不同于SIGTERM的方式处理SIGINT？如果是这样,那将是什么原因以及如何处理不同？