O processo continua a ser executado após receber SIGINT não detectado (Ctrl-C do terminal)

Question

Estou tentando interromper alguns processos em execução com Ctrl-C do terminal no Centos7; alguns fazem, outros não.

Um dos processos problemáticos (Process-A) é um makefile GNU com nada extravagante; apenas o arquivo único usual faz o sistema. O outro (Process-B) é um aplicativo C que escuta no soquete TCP.

A seguir estão minhas observações quando executo (e tento encerrar) alguns desses processos problemáticos:

• O processo A não morre com Ctrl-C . Quando marcado com strace -f e Ctrl-C é pressionado, strace se desconecta dos subprocessos e strace fecha mas o Process-A continua sem logs de strace (isso é muito estranho).
• O processo B não morre com Ctrl-C . Quando iniciado com strace -f , captura SIGINT e termina como esperado.
• O processo B não morre com Ctrl-C . Quando suprimida para background e envia uma SIGINT externamente ( kill -s SIGINT PID ) ainda a descarta enquanto um SIGTERM a mata.

Detalhes adicionais:

1. Com um programa de teste, verifiquei que meu terminal está enviando um SIGINT para o processo (o programa de teste sai).
2. Em nenhum dos processos, estou capturando manualmente qualquer sinal.
3. Tentei vários aplicativos de terminal para observar um comportamento idêntico.

Precisa de clareza sobre como esses sinais estão em cascata e o que estou perdendo aqui. Como se faz para depurar essas questões?

Update1:

Eu corro grep 'search_string' para fazer o grep esperar pela entrada em STDIN . Agora não consigo fechá-lo com Ctrl-C . Começando a se perguntar se é um problema específico do ambiente.

Update2:

Após algum trabalho, descobri que o script RVM de origem, conforme abaixo, está causando esse problema.

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

    

Answer 1

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

Isso não é nada estranho, strace não está manipulando o sinal, mas o Process-A está. O sinal que resulta de control + c é enviado para todos os processos no grupo de processos em primeiro plano (a menos que o terminal está em algum outro modo) que, para o caso de teste abaixo, inclui strace e perl . strace sai, mas o processo de ignorar sinal continua a ser executado até ser morto por outros meios.

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

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

Isso aponta para um problema de configuração do shell; grep provavelmente herdou um manipulador de sinal de um processo pai que, nesse caso, seria seu shell. Eu tenho um script blocksig que ilustra este caso:

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

No entanto, no seu caso, é o seu shell e não blocksig , que é o processo pai. O que acontece quando você muda para outro shell ou inicia seu shell sem ler os típicos arquivos rc ? Você tem alguma configuração de trap ou configuração personalizada de trabalho ou monitoramento de tarefas na sua configuração de shell?