I am trying to interrupt some running processes with Ctrl-C from the terminal in Centos7; some do, some don't.

One of the problematic processes (Process-A) is a GNU makefile with nothing fancy; just the usual single file make system. The other (Process-B) is an C application that listens on TCP socket.

Following are my observations when I run (and try to terminate) some of these problematic processes:

  • Process-A doens't die with Ctrl-C. When stared with strace -f and Ctrl-C is pressed, strace detaches from of the sub processes and strace quits but Process-A continues without strace logs (this is very strange).
  • Process-B doesn't die with Ctrl-C. When started with strace -f, catches SIGINT and and terminates as expected.
  • Process-B doesn't die with Ctrl-C. When suppressed to background and sent a SIGINT externally (kill -s SIGINT PID) still discards it while a SIGTERM kills it.

Additional Details:

  1. With a test program I verified that my terminal is sending a SIGINT to the process (the test program does exit).
  2. In neither of the processes, I am manually capturing any signals.
  3. Tried with multiple terminal applications to observe identical behavior.

Need some clarity on how these signals are cascaded and what I am missing here. How does one go about debugging such issues?


I run grep 'search_string' to make grep wait for input in STDIN. Now I'm unable to close it with Ctrl-C. Beginning to wonder if its an environment specific issue.


After some work, discovered that sourcing RVM script as below is causing this issue.

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

Process-A does not die with Ctrl-C but strace does (this is very strange)

This is not at all strange, strace is not handling the signal but Process-A is. The signal that results from control+c is sent to all processes in the foreground process group (unless the terminal is in some other mode) which for the test case below includes strace and perl. strace exits but the signal-ignoring process continues to run until killed by some other means.

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

I run grep 'search_string' to make grep wait for input in STDIN. Now I'm unable to close it with Ctrl-C.

This does point to a shell configuration problem; grep likely has inherited a signal handler from a parent process which in this case would be your shell. I have a blocksig script that illustrates this case:

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

However in your case it's your shell and not blocksig that is the parent process. What happens when you switch to some other shell or start your shell without reading the typical rc files? Do you have any trap setup or customized job or job monitoring configuration in your shell configuration?

| improve this answer | |
  • Thanks for the answer. I removed my .bashrc and I was able to kill grep with Ctrl+C. So I suppose that is causing the issue. I isolated the contents of the file few at a time to narrow down the exact cause without much luck. Any ideas on how to debug this? – sidcha Oct 24 '18 at 18:54
  • did you find anything related to trap (or a source or . file that includes trap?) otherwise it might be some shopt that could differ between a bare config and yours – thrig Oct 24 '18 at 19:44
  • Finally I found that sourcing RVM script at ~/.rvm/scripts/rvm was causing this issue. Should I report this to the RVM maintainer? – sidcha Oct 25 '18 at 10:14
  • you probably should edit your post to show what the offending code looks like. reporting it may also be a good idea, as whatever that code is is kinda breaking things – thrig Oct 25 '18 at 13:58
  • I have updated the question with the lines that caused the issue. Also, I will try to reach the RVM maintainer. – sidcha Oct 26 '18 at 13:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.