程序拦截、内部处理和忽略 SIGINT 信号的合法原因

Question

我们知道，除了SIGKILL和之外SIGSTOP，程序还可以拦截 IPC 信号，并运行其内部处理程序来绕过默认处理程序的操作。

我至少能想到一个利用SIGINT信号执行此操作的充分理由。

• 即实现一个信号处理程序，在恢复到终止进程的默认信号操作之前，执行最后一次备份、保存内存转储或写入日志。

我还可以想到恶意软件可能捕获并阻止 SIGINT 的一个很好的理由：

• 即延长进程的执行时间。对于大多数用户来说，Ctrl+C是大多数终端用户的键盘快捷键，有很多人不知道Ctrl+ Z（SIGTSTP它只会停止进程，保留在终端中jobs），更不用说Ctrl+了\，它发送SIGQUIT并创建一个核心转储。

• 如果Ctrl+C被捕获并被阻止，此类用户可能会尝试打开另一个终端窗口，并运行以下内容：

  ps aux | grep [process name]
  

  获取进程PID，并执行SIGKILL

  kill -9 [$PID]
  

• 同样，连接到远程计算机上的终端会话的用户将尝试与新的终端会话建立第二个连接，并通过类似的进程/PID 搜索来终止罪魁祸首。显然，这种策略可能只会延长进程运行时间很短一段时间，但即使使用 10MB/s 高带宽连接的文件传输过程额外 3 分钟，也会传输近 2 GB 的额外数据，因此肯定有一些优点它。

然而，最近我注意到——也许只是因为我开始关注它——有些程序似乎属于另一个子集。

• 这些程序是开源的，并且对软件包进行了足够的维护和检查，隐藏主要的恶意软件代码似乎不太可能。

• vim它们不像其他文本编辑器那样控制键盘输入

• 他们有内部处理程序来捕获 SIGINT 并完全忽略它。没有最终的进程终止，并且据所知，没有尝试最后的关键任务。

我的问题：

• 进程出于合法目的可能选择拦截但完全丢弃 SIGINT 是否有可能的原因？

• 换句话说，是否有充分的理由（从代码或系统的角度来看）或情况，捕获并忽略 SIGINT 比其已知的默认操作（终止正在运行的进程）更有利？

Answer 1

正如您所发现的，程序忽略 SIGINT 的最可能原因是错误。行为良好的程序应该尊重信号，通常SIGINT 意味着“请退出”，但这不是必需的行为。程序完全有权将 SIGINT 用于其自身目的。类似地，许多程序（通常是守护进程）使用 SIGHUP 来表示“重新加载配置文件”，而不是“您的控制终端已挂起”。

• 长时间运行的程序或守护进程可能使用 SIGINT 来表示“中断我当前正在处理的事情，并继续执行下一个任务”。
• 等待事件的程序可能使用 SIGINT 来表示“停止等待 [事件] 并继续”（SIGTERM 可能表示替代的“停止等待 [事件] 并终止”）。
• 信号经常被发送到多个进程；如果程序有理由相信它不是预期的接收者，它可能会忽略它。
• 程序可能（正确或错误地）相信它比你更了解，并简单地忽略中断和其他可选信号以继续它正在处理的事情；例如，像磁盘修复过程这样的关键任务可能会合理地忽略用户中途停止的请求。

当然，出于这些原因或任何其他原因，程序是否应该以不同的方式处理 SIGINT 是值得商榷的。这可能会让像您这样期望程序能够快速退出的用户感到惊讶或困惑。因此，考虑以不寻常的方式处理 SIGINT 的行为良好的程序应该确保这种行为对于（大多数）用户来说是有意义的。

本文（链接自Wikipedia）详细介绍了 SIGINT 和正确处理，并讨论了在实现 SIGINT 处理时值得考虑的一些边缘情况。