☰

何时强制以编程方式发送 SIGINT？

tag-icon • tag-icon kill signals sigint
何时强制以编程方式发送 SIGINT？

我知道推荐的方法终止前台进程是通过SIGTERM信号进行的，因为它为进程本身提供了清理/释放资源的机会。该信号只能通过命令生成/发送，可以通过任何命令生成/发送kill pkill killall- 直到这里我都可以。此外，它是默认这些命令的信号。

现在我知道SIGINT信号了中断一个过程。因此“相似”为终止。

但我读到了以下答案（摘录）：

SIGINT并SIGQUIT旨在具体来说为了来自终端的请求：可以指定特定的输入字符来生成这些信号（取决于终端控制设置）。的默认操作与 的默认操作和 的不可更改操作SIGINT是相同类型的进程终止；SIGTERMSIGKILL

直到这里根据答案由组合键（ + ）SIGINT触发ctrlc和 理论上 SIGINT与 做相同的事情SIGTERM，它即将：给程序本身清理/释放资源的机会。

老实说，在阅读了很多教程之后，我无法明确地找到并确认该信息。例如，它来自：

在许多地方使用这些信号中断和终止条款。

此外，根据相同的答案，存在@乔纳森莱夫勒的评论（摘录）为：

这是关键点:SIGINT并且SIGQUIT可以在程序运行时使用单个字符从终端生成。其他信号必须由另一个程序以某种方式生成（例如通过命令kill）。SIGINT没有那么暴力SIGQUIT；后者产生一个核心转储

到目前为止，一个可能的结论是：SIGINT可以通过组合键或命令触发，并且SIGTERM只能通过命令触发。

发帖理由：如果理论上 SIGINT与SIGTERM

问题

  • 什么时候强制SIGINT以编程方式发送？

它出现在 中kill -l，因此可以使用它。

额外问题

再说一遍，如果理论上 SIGINT与 - 的作用相同SIGTERM，并且两者都可以被忽略/阻止/处理

  • 为什么被创建SIGINT？
  • 为什么ctrl+c从一开始就没有被赋值给SIGTERM？

老实说我以为那SIGINT是不是安全，因为它中断该过程因此会使一些数据处于不一致/完整的状态

答案1

这默认动作和SIGINT（SIGTERM以及许多其他信号）的作用是终止进程。这记录在例如Linux 手册页signal(7)，请参阅“标准信号”下的表格，部分引用如下。在实践中也是如此。

那里的表的一部分：

       Signal      Standard   Action   Comment
────────────────────────────────────────────────────────────────────────
       SIGHUP       P1990      Term    Hangup detected on controlling terminal
                                       or death of controlling process
       SIGINT       P1990      Term    Interrupt from keyboard
       SIGKILL      P1990      Term    Kill signal
       SIGTERM      P1990      Term    Termination signal

现在，这就是默认动作。对于大多数信号，接收它们的程序可以通过预先设置信号处理函数来捕获它们，或者完全忽略它们。知道 aSIGINT通常是由用户按 Ctrl-C 发送的，并且SIGTERM通常是由要求接收程序退出的其他程序发送的，程序可以决定以不同的方式处理它们。

交互式程序可能决定结束所有长时间运行的任务，SIGINT而不是立即退出，让用户选择退出或执行不同的操作。一直以来仍然退出SIGTERM。话又说回来，一个更简单的程序可能会为它们设置相同的处理程序（可能还有其他一些处理程序，例如SIGHUP）：保存所有数据并退出的处理程序。

举个例子，我在 Debian 上尝试的交互式 Bash shell 会清除当前命令行SIGINT而不执行任何操作；忽略SIGTERM（有点令人惊讶，但这可能与向整个进程组发送信号有关）；并退出SIGHUP（因为SIGHUP意味着终端连接消失，因此尝试读取更多命令是没有意义的）。

大多数信号允许接收进程在（可能）退出之前进行任何清理。两个异常信号是SIGKILL和SIGSTOP，其中不能被捕获或忽略，但它们会无条件地立即破坏或停止该进程，而不让它进行任何清理。 （尽管请注意，内核仍然会执行操作系统资源所需的任何清理，但这里的清理更多的是关于进程内存中未保存的数据。）

当然，还有其他信号也默认终止进程。就像SIGALRM，它是由系统调用设置的定时器发送的alarm()。虽然默认行为在某些情况下可能很有用，但它作为通用闹钟更有用，例如告诉程序执行某些周期性任务。

答案2

何时强制以编程方式发送 SIGINT？

答案是：从来没有。发送信号从来都不是强制性的。信号是用来捕获的，不是用来发送的。

为什么创建 SIGINT？为什么ctrl + c从一开始就没有分配给SIGTERM？

答案在于信号代码 - SIGINT=2、SIGKILL=9、SIGTERM=15。 SIGINT 首先被创建并分配给 ^C。然后人们发现，^C有时必须由应用程序处理（或可以处理），因此添加了新的“特殊”SIGKILL供kill工具使用。然后这个信号被许多应用程序捕获，并且发明了SIGTERM，希望这个信号无法捕获......

要点是：man 7 signalas中描述的所有信号terminate application都确实如此 - 默认情况下终止，应该终止，通常终止...但是由于应用程序可以捕获并处理它喜欢的任何信号，无论它喜欢什么 - 这一切都变得更像是一个建议，比一条规则。这里的关键词是“传统”。

相关内容