SIGINT 与其他终止信号(例如 SIGTERM、SIGQUIT 和 SIGKILL)有何关联? [英] How does SIGINT relate to the other termination signals such as SIGTERM, SIGQUIT and SIGKILL?
问题描述
在 POSIX 系统上，终止信号通常具有以下顺序(根据许多 MAN 页面和 POSIX 规范):
On POSIX systems, termination signals usually have the following order (according to many MAN pages and the POSIX Spec):
SIGTERM - 礼貌地要求进程终止.它应正常终止，清理所有资源(文件、套接字、子进程等)，删除临时文件等.
SIGTERM - politely ask a process to terminate. It shall terminate gracefully, cleaning up all resources (files, sockets, child processes, etc.), deleting temporary files and so on.
SIGQUIT - 更有力的请求.它将终止不优雅，仍然清理绝对需要清理的资源，但可能不会删除临时文件，可能会在某处写入调试信息；在某些系统上，还会写入核心转储(无论信号是否被应用程序捕获).
SIGQUIT - more forceful request. It shall terminate ungraceful, still cleaning up resources that absolutely need cleanup, but maybe not delete temporary files, maybe write debug information somewhere; on some system also a core dump will be written (regardless if the signal is caught by the app or not).
SIGKILL - 最有力的请求.进程甚至不会被要求做任何事情，但系统会清理进程，不管它喜欢与否.很可能写入了核心转储.
SIGKILL - most forceful request. The process is not even asked to do anything, but the system will clean up the process, whether it like that or not. Most likely a core dump is written.
SIGINT 如何适应那幅画?当用户按下 CRTL+C 时，CLI 进程通常由 SIGINT 终止，但是后台进程也可以使用 KILL 实用程序由 SIGINT 终止.我在规范或头文件中看不到的是 SIGINT 是否比 SIGTERM 更强大或更不强大，或者 SIGINT 和 SIGTERM 之间是否有任何区别.
How does SIGINT fit into that picture? A CLI process is usually terminated by SIGINT when the user hits CRTL+C, however a background process can also be terminated by SIGINT using KILL utility. What I cannot see in the specs or the header files is if SIGINT is more or less forceful than SIGTERM or if there is any difference between SIGINT and SIGTERM at all.
更新:
迄今为止我发现的对终止信号的最佳描述是 GNU LibC 文档.它很好地解释了 SIGTERM 和 SIGQUIT 之间的预期差异.
The best description of termination signals I found so far is in the GNU LibC Documentation. It explains very well that there is an intended difference between SIGTERM and SIGQUIT.
它说的是 SIGTERM:
It says about SIGTERM:
这是礼貌地要求程序终止的正常方式.
It is the normal way to politely ask a program to terminate.
它说的是 SIGQUIT:
And it says about SIGQUIT:
[...] 并在终止进程时产生核心转储，就像程序错误信号一样.您可以将其视为用户检测到"的程序错误情况.[...]在处理 SIGQUIT 时最好省略某些类型的清理.例如，如果程序创建临时文件，它应该通过删除临时文件来处理其他终止请求文件.但是 SIGQUIT 最好不要删除它们，以便用户可以在结合核心转储.
[...] and produces a core dump when it terminates the process, just like a program error signal. You can think of this as a program error condition "detected" by the user. [...] Certain kinds of cleanups are best omitted in handling SIGQUIT. For example, if the program creates temporary files, it should handle the other termination requests by deleting the temporary files. But it is better for SIGQUIT not to delete them, so that the user can examine them in conjunction with the core dump.
而且 SIGHUP 也解释得很好.SIGHUP 并不是一个真正的终止信号，它只是意味着与用户的连接"已经丢失，因此应用程序不能期望用户读取任何进一步的输出(例如 stdout/stderr 输出)并且没有期望来自用户不再.对于大多数应用程序，这意味着它们最好退出.理论上，当收到 SIGHUP 并且现在作为后台进程运行时，应用程序也可以决定它进入守护程序模式，将输出写入配置的日志文件.对于大多数已经在后台运行的守护进程，SIGHUP 通常意味着它们将重新检查其配置文件，因此您在编辑配置文件后将其发送到后台进程.
And SIGHUP is also explained well enough. SIGHUP is not really a termination signal, it just means the "connection" to the user has been lost, so the app cannot expect the user to read any further output (e.g. stdout/stderr output) and there is no input to expect from the user any longer. For most apps that mean they better quit. In theory an app could also decide that it goes into daemon mode when a SIGHUP is received and now runs as a background process, writing output to a configured log file. For most daemons already running in the background, SIGHUP usually means that they shall reexamine their configuration files, so you send it to background processes after editing config files.
然而在这个页面上没有对 SIGINT 有用的解释，除了它是由 CRTL+C 发送的.是否有任何理由以不同于 SIGTERM 的方式处理 SIGINT?如果是这样，这是什么原因，处理方式会有什么不同?
However there is no useful explanation of SIGINT on this page, other than that it is sent by CRTL+C. Is there any reason why one would handle SIGINT in a different way than SIGTERM? If so what reason would this be and how would the handling be different?
推荐答案
SIGTERM 和 SIGKILL 用于通用终止此进程"请求.SIGTERM(默认)和 SIGKILL(总是)将导致进程终止.SIGTERM 可能会被进程捕获(例如，以便它可以根据需要进行自己的清理)，甚至完全忽略；但 SIGKILL 不能被捕获或忽略.
SIGTERM and SIGKILL are intended for general purpose "terminate this process" requests. SIGTERM (by default) and SIGKILL (always) will cause process termination. SIGTERM may be caught by the process (e.g. so that it can do its own cleanup if it wants to), or even ignored completely; but SIGKILL cannot be caught or ignored.
SIGINT 和 SIGQUIT 专门用于来自终端的请求:可以分配特定的输入字符来生成这些信号(取决于终端控制设置).SIGINT 的默认操作与 SIGTERM 的默认操作和 SIGKILL 的不可更改操作相同类型的进程终止；SIGQUIT 的默认操作也是进程终止，但可能会发生其他实现定义的操作，例如生成核心转储.如果需要，可以被进程捕获或忽略.
SIGINT and SIGQUIT are intended specifically for requests from the terminal: particular input characters can be assigned to generate these signals (depending on the terminal control settings). The default action for SIGINT is the same sort of process termination as the default action for SIGTERM and the unchangeable action for SIGKILL; the default action for SIGQUIT is also process termination, but additional implementation-defined actions may occur, such as the generation of a core dump. Either can be caught or ignored by the process if required.
SIGHUP，如您所说，旨在表明终端连接已丢失，而不是作为终止信号.但是，同样，SIGHUP 的默认操作(如果进程没有捕获或忽略它)是以与 SIGTERM 等相同的方式终止进程.
SIGHUP, as you say, is intended to indicate that the terminal connection has been lost, rather than to be a termination signal as such. But, again, the default action for SIGHUP (if the process does not catch or ignore it) is to terminate the process in the same way as SIGTERM etc. .
POSIX 定义中有一个表格用于 signal.h，其中列出了各种信号及其默认操作和用途，以及 通用终端接口一章包含更多关于终端相关信号的详细信息.
There is a table in the POSIX definitions for signal.h which lists the various signals and their default actions and purposes, and the General Terminal Interface chapter includes a lot more detail on the terminal-related signals.
这篇关于SIGINT 与其他终止信号(例如 SIGTERM、SIGQUIT 和 SIGKILL)有何关联?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
