我们知道 - 除了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 比其已知的默认操作（终止正在运行的进程）更有利？
答案1
正如您所发现的，程序忽略 SIGINT 的最可能原因是错误。行为良好的程序应该尊重信号，并且通常SIGINT 表示“请退出”，但这不是必需的行为。程序完全有权将 SIGINT 用于其自身目的。类似地，许多程序（通常是守护进程）使用 SIGHUP 来表示“重新加载配置文件”，而不是“您的控制终端已挂起”。
- 长时间运行的程序或守护进程可能使用 SIGINT 来表示“中断当前的我正在做的事情，然后继续下一个任务”。
- 等待事件的程序可能使用 SIGINT 来表示“停止等待 [事件] 并继续”（SIGTERM 可能表示替代的“停止等待 [事件] 并终止”）。
- 信号经常被发送到多个进程；如果程序有理由相信它不是预期的接收者，它可能会忽略它。
- 程序可能（正确或错误地）相信它比你更了解，并简单地忽略中断和其他可选信号以继续它正在处理的事情；例如，像磁盘修复过程这样的关键任务可能会合理地忽略用户中途停止的请求。
当然无论是程序应该由于这些或任何其他原因，以不同的方式处理 SIGINT 是有争议的。这可能会让像您这样期望程序能够快速退出的用户感到惊讶或困惑。因此，考虑以不寻常的方式处理 SIGINT 的行为良好的程序应该确保这种行为对于（大多数）用户来说是有意义的。
本文（链接自维基百科），详细介绍了 SIGINT 和正确处理，并讨论了在实现 SIGINT 处理时值得考虑的一些边缘情况。