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终止，但是，后台进程也可以由SIGINT使用KILL实用程序终止.我在规范或头文件中看不到的是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 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.
但是，除CRTL + C发送的信息外，此页面上没有SIGINT的有用解释.是否有任何理由会以不同于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 定义中有一个表，用于常规终端接口" 一章详细介绍了与终端相关的信号.
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屋！
