☰

收到未捕获的 SIGINT 后进程继续运行（来自终端的 Ctrl-C）

tag-icon • tag-icon linux process signals gnu-make
收到未捕获的 SIGINT 后进程继续运行（来自终端的 Ctrl-C）

我试图Ctrl-C从 Centos7 的终端中断一些正在运行的进程；有些会，有些不会。

有问题的进程之一（进程-A）是一个没有任何花哨的 GNU makefile；只是通常的单文件制作系统。另一个（进程 B）是一个侦听 TCP 套接字的 C 应用程序。

以下是我运行（并尝试终止）其中一些有问题的进程时的观察结果：

  • 进程 A 不会随着Ctrl-C.当使用 strace -f 启动并Ctrl-C按下时，strace 会脱离子进程并strace 退出但是 Process-A 继续运行而没有 strace 日志（这很奇怪）。
  • Process-B 不会随Ctrl-C.当以 开始时strace -f，捕获 SIGINT 并按预期终止。
  • Process-B 不会随Ctrl-C.当抑制到后台并从外部发送 SIGINT ( kill -s SIGINT PID) 时，仍然会丢弃它，而 SIGTERM 会杀死它。

额外细节：

  1. 通过测试程序，我验证了我的终端正在向进程发送 SIGINT（测试程序确实退出）。
  2. 在这两个过程中，我都没有手动捕获任何信号。
  3. 尝试使用多个终端应用程序来观察相同的行为。

需要清楚地了解这些信号是如何级联的以及我在这里缺少的内容。如何调试此类问题？

更新1：

我运行grep 'search_string'让 grep 等待输入STDIN。现在我无法用 关闭它Ctrl-C。开始怀疑这是否是环境特定问题。

更新2：

经过一番工作后，发现如下所示的源 RVM 脚本导致了此问题。

if [ -f ~/.rvm/scripts/rvm ]; then
  source ~/.rvm/scripts/rvm
  export PATH="$PATH:$HOME/.rvm/bin"
fi

答案1

Process-A 不会因 Ctrl-C 而终止，但 strace 会终止（这很奇怪）

这一点也不奇怪，strace不是处理信号，而是 Process-A 处理。产生的信号control+c被发送到前台进程组中的所有进程（除非终点站处于某种其他模式），下面的测试用例包括strace和perl。strace退出，但信号忽略进程继续运行，直到被其他方式杀死。

% strace perl -E '$SIG{INT}="IGNORE";while(1){say $$;sleep 1}'
...
% 9520
9520
9520
kill9520
 9520
%

我运行 grep 'search_string' 以使 grep 等待 STDIN 中的输入。现在我无法使用 Ctrl-C 关闭它。

这确实表明 shell 配置有问题；grep可能从父进程继承了一个信号处理程序，在本例中是您的 shell。我有一个blocksig说明此案例的脚本：

% grep asdf
^C
% blocksig grep asdf
^C^C^C^C^C^]^\zsh: quit       blocksig grep asdf
%

但是，在您的情况下，这是您的外壳程序，而不是blocksig父进程。当您切换到其他 shell 或启动 shell 而不读取典型rc文件时会发生什么？您的 shell 配置中是否有任何trap设置或自定义作业或作业监控配置？

相关内容