主页 / unix / 问题 / 477484
Accepted
sidcha
Asked: 2018-10-25 03:26:25 +0800 CST

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

  • 772

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

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

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

  • Process-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
linux process

1 个回答

  1. Best Answer

    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 或在不读取典型rc文件的情况下启动 shell 时会发生什么？您的 shell 配置中是否有任何trap设置或自定义作业或作业监控配置？

    • 0

相关问题