SIGINT e SIGTSTP ignorados pelas aplicações mais comuns

Question

Após a última atualização para o meu Fedora, um comportamento estranho começou a ocorrer nos aplicativos do terminal X. Não consigo parar nenhum processo usando Ctrl + C, isso só resulta em imprimir ^C no console. Da mesma forma, Ctrl + Z imprime ^Z e o processo continua. Ambos funcionam bem em consoles virtuais não gráficos.

Eu verifiquei stty -a e parece perfeitamente normal:

speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Isto é independente do terminal (gnome-terminal, terminal XFCE4, xterm). Mais tarde, notei que ele pode não ser causado pelo terminal: INT ou TSTP enviados diretamente para o respectivo processo também são ignorados. Isso inclui vários aplicativos que usei para finalizar usando Ctrl + C regularmente (e que geralmente não têm meios melhores de sair): cat , find , tail -f , java , ping , mplayer quando preso em um arquivo quebrado ...

Mesmo bash ignora Ctrl + C quando quero interromper uma linha de comando que estou inserindo e, em seguida, mudei de ideia (sem ^C é impresso nesse caso). Eu preciso excluir caracteres por caracteres (dos quais pode haver centenas se a conclusão do nome do arquivo tiver sido usada) ou intencionalmente executar o comando indesejado. Estranhamente, vim reconhece Ctrl + C - apenas para dizer "use: quit", é claro.

Isso é extremamente irritante e me impede de trabalhar de forma eficiente. Tudo estava funcionando até recentemente, talvez uma semana atrás, mais ou menos. Não consigo encontrar nenhuma causa possível no Google, talvez esteja tentando termos de pesquisa incorretos ou identificando erroneamente o problema principal. O que poderia ser e como eu poderia reverter o comportamento padrão, por favor?

Atualizar

Ctrl + Z funciona às vezes . Parece que no primeiro terminal que eu inicio após o login, ele pára o comando de execução, mas para de funcionar depois disso.

    

Answer 1

Eu suspeitaria do seu ambiente de trabalho. Qual você usa?

Nova resposta.

Algo no caminho do init para o seu shell define o SIGINT e o SIGTSTP para serem ignorados. este é eventualmente herdado pelo seu shell. Você pode usar este pequeno programa para gerar qualquer programa com os sinais redefinidos para o padrão.

#include <signal.h>

int main(int argc, char **argv)
{
    signal(SIGTSTP, SIG_DFL);
    signal(SIGINT, SIG_DFL);
    execvp(argv[1], argv+1);
}

    

Answer 2

Para quem pode enfrentar o mesmo problema:

Eu tenho empregado uma variação da solução fstx e funciona bem para mim em todos os casos (logins aninhados, SSH, ...) agora.

Um pequeno utilitário precisava ser escrito em C, compilado e colocado em algum lugar no $PATH :

sig.c

#include <signal.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    sigset_t mask;
    sigfillset(&mask);
    sigprocmask(SIG_UNBLOCK, &mask, NULL);
    return execvp(argv[1], argv+1);
}

Em seguida, essa pequena verificação no início de .bashrc garante que nenhum sinal seja bloqueado:

if ( grep SigBlk /proc/self/status | grep -qv 00000 )
then
    exec sig $0 $@
fi

    

Answer 3

Veja uma solução semelhante àquela já fornecida. Não requer que você compile um programa especial, então algumas pessoas podem achar mais conveniente.

exec ksh -c 'exec $SHELL'

Instale ksh com yum install ksh se você ainda não o tiver feito.