Os processos não respondem aos meus sinais

Question

Eu tenho um comportamento estranho no meu sistema.

Quando invoco um comando no shell (bash versão 4.2.45 (1) -release), digamos top ou cat , o programa em execução (o processo) não responde ao Ctrl + C . Eu até tentei executar kill -2 <pid> e kill -15 <pid> , mas isso não ajudou. No entanto, posso matar processos com SIGKILL .

Eu possuo o processo, eu até tentei enviar um sinal para o processo (sinais 2 e 15) como root mas ele não respondeu. Eu posso sair do top se eu pressionar q .

Alguma idéia sobre o problema? Ou alguma dica para solucionar o problema?

UPDATE 1

cat e top foram apenas exemplos. Todos os processos possuem o mesmo comportamento. Eu tentei escrever um programa simples para dormir apenas (sem manipulador de sinal) e tive o mesmo comportamento.

UPDATE 2

Eu escrevi um pequeno programa para dormir apenas. Desta vez eu instalei o manipulador de sinal para capturar SIGTERM e SIGINT . Quando invoquei kill -15 <pid> (e assim com -2 ), meu programa não recebeu o sinal!

Eu também atualizei o kernel para 3.11.10-100.fc18.i686 e ainda tenho o mesmo problema.

    

Answer 1

Versões recentes dos drivers proprietários da nVidia (possivelmente combinados com outras versões recentes de bibliotecas) possuem um bug que faz com que eles corrompam a máscara de sinal.

Você pode ver máscaras de sinal como esta:

anthony@Zia:~$ ps -eo blocked,pid,cmd | egrep -v '^0+ '
         BLOCKED   PID CMD
fffffffe7ffbfeff   605 udevd --daemon
0000000000000002  4052 /usr/lib/policykit-1/polkitd --no-debug
0000000000087007  4646 /usr/sbin/mysqld --basedir=/usr […]
0000000000010000 15508 bash

É sobre como deve ser. Se você executar isso em um sistema com os drivers proprietários da nVidia, verá todos os tipos de valores malucos para BLOCKED , para muitos de seus programas - incluindo, provavelmente, todos os que não se comportam bem.

Observe que as máscaras de sinal são transmitidas de pai para filho por meio de fork / exec , portanto, assim que um processo pai tiver um corrompido, todos os filhos gerados a partir desse ponto também serão enviados.

Veja também minha pergunta Após a atualização, o botão X na barra de título não fechará mais o xterm e vários bugs de distro que você poderá encontrar agora, sabendo qual pacote observar. Você pode modificar o código em minha resposta a essa pergunta para redefinir a máscara de sinal para nenhum bloqueado (Elide sigaddset e altere SIG_UNBLOCK para SIG_SETMASK ).

    

Answer 2

Acho que esse é o comportamento desejado de top : ele sai apenas de um comando "q" do teclado.

O código de top provavelmente instala as funções do receptor de sinais, com uma chamada de sistema signal() ou uma chamada de sistema sigaction() . Meu palpite seria que quando top periodicamente atualiza a tela, ele recebeu um sinal, possível de uma chamada de sistema alarm() ou algo assim.

Tem certeza de que cat não sai em um control-C ou control- \? Ambos os acordes geralmente geram SIGINT e SIGQUIT respectivamente. cat não parece se beneficiar da recuperação de nenhum desses dois sinais.

Uma forma de verificar o que o seu driver tty acha que são os principais acordes para o SIGINT e o SIGQUIT:

stty -a

Na minha máquina, diz algo como:

speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; 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 -cdtrdsr
-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

O "intr = ^ C" e "quit = ^ \" significam "Enviar SIGINT para o processo de primeiro plano atual no Control-C" e "Enviar SIGQUIT para o processo de primeiro plano atual no Control-backslash". Esses dois se mudaram de alguma forma?

Você pode ter seu shell configurado para interceptar sinais. Em zsh e bash, o comando:

trap "" INT

mantém o controle-C (no mesmo xterm) de matar uma invocação subseqüente de cat . Mas essa "armadilha" não impede que kill -QUIT faça o processo cat sair. No entanto, você deve verificar seus arquivos bash ou zsh ou ksh dot para trap "" INT invocações.

Você não menciona qual versão do kernel, qual distro e qual shell está usando. A menção dessas coisas pode te dar uma resposta melhor.