Ctrl + c não está funcionando para determinados aplicativos no Linux

2

É um problema muito estranho, mas em novos sistemas (Fedora, Ubuntu) ctrl + c não tem efeito para certas ferramentas:

se eu executar yum list, que é executado por quase um minuto, não posso interromper a execução com ctrl + c

$time yum list >/dev/null
^C^C^C^C^C^C^C^C^C

A execução do comando não irá parar.

No entanto, para interromper a busca é possível.

$ time find / >/dev/null 2>&1
^C

real    0m0.741s
user    0m0.033s
sys     0m0.124s

Estou curioso sobre o que está causando isso.

Eu tenho que seguir as configurações:

$ stty -a
speed 38400 baud; rows 36; columns 158; 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
-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

Ainda não consegui encontrar a descrição do problema, agradeço que alguém seja desse tipo para lançar alguma luz.

Obrigado antecipadamente.

    
por Istvan 11.12.2010 / 14:16

6 respostas

1

Este é um bug do yum. Parece que há mais e mais desenvolvedores de Linux acham que é uma boa idéia ignorar o tratamento de sinais padrão e fazer com que seu aplicativo não reaja a sinais padrão.

homem 7 sinal

   Standard Signals
       Linux  supports the standard signals listed below.  Several signal numbers are architecture-dependent, as indicated in the "Value" col-
       umn.  (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for ix86, ia64, ppc, s390,  arm
       and sh, and the last one for mips.  A - denotes that a signal is absent on the corresponding architecture.)

       First the signals described in the original POSIX.1-1990 standard.

       Signal     Value     Action   Comment
       ----------------------------------------------------------------------
       SIGHUP        1       Term    Hangup detected on controlling terminal
                                     or death of controlling process
       SIGINT        2       Term    Interrupt from keyboard
       SIGQUIT       3       Core    Quit from keyboard
       SIGILL        4       Core    Illegal Instruction
       SIGABRT       6       Core    Abort signal from abort(3)
       SIGFPE        8       Core    Floating point exception
       SIGKILL       9       Term    Kill signal
       SIGSEGV      11       Core    Invalid memory reference
       SIGPIPE      13       Term    Broken pipe: write to pipe with no
                                     readers
       SIGALRM      14       Term    Timer signal from alarm(2)
       SIGTERM      15       Term    Termination signal
       SIGUSR1   30,10,16    Term    User-defined signal 1
       SIGUSR2   31,12,17    Term    User-defined signal 2
       SIGCHLD   20,17,18    Ign     Child stopped or terminated
       SIGCONT   19,18,25    Cont    Continue if stopped
       SIGSTOP   17,19,23    Stop    Stop process
       SIGTSTP   18,20,24    Stop    Stop typed at tty
       SIGTTIN   21,21,26    Stop    tty input for background process
       SIGTTOU   22,22,27    Stop    tty output for background process

Este é um mau hábito.

    
por 11.12.2010 / 16:18
6

Alguns aplicativos interceptam SIGINT devido a interações estranhas com outras bibliotecas. Você pode tentar enviar um SIGQUIT (via Ctrl \ como dado pela sua stty output).

    
por 11.12.2010 / 14:25
1

Definitivamente relacionado ao manuseio de sinais no comando que você está chamando. Veja um número de bugs abertos ao redor do manuseio:

Red Hat Bugzilla – Bug List

https://bugzilla.redhat.com/buglist.cgi?quicksearch=yum+Ctrl-C

Parece que Ctrl-C ( SIGINT ) pode ter sido usado para controlar outro comportamento (pular para o próximo espelho) em vez da intenção usual (matar o processo).

Re: por que SIGQUIT não parece fazer nada de útil - pode não haver um manipulador definido.

    
por 11.12.2010 / 17:39
1

Alguns aplicativos apenas interceptam SIGINT como Ignacio mencionou, outros capturam todas as entradas do teclado.

Se o C-c não funcionar, você pode tentar o já mencionado C- \ e se isso não funcionar, tente apenas fazer o processo em segundo plano: C-z. e depois mate-o com kill -s SIGKILL <pid>

    
por 11.12.2010 / 14:37
0

Isso geralmente acontece quando o aplicativo está em um estado em que ele não é realmente capaz de responder a sinais porque não é capaz de retomar a execução a partir da fila do planejador de CPU. Um bom exemplo é quando o aplicativo está travado esperando por uma operação de bloqueio (E / S de disco síncrono no thread principal, swap in / out, bloqueio de E / S de rede, etc.) Dado que isso é yum, estou supondo que O tempo limite é conectado a uma ou mais das origens definidas em suas configurações de repositório / lista de espelhos, mas poderia facilmente ser um problema de E / S de disco acessando seus caches, o banco de dados RPM (incluindo corrupção de BDB) ou qualquer outra coisa.

Uma boa maneira de testar esse comportamento com qualquer aplicativo arbitrário: monte um compartilhamento NFS, puxe o servidor NFS offline e tente usar qualquer programa que tente abrir esse diretório (encontre ou / bin / ls são bons exemplos). Ele não responderá a nada além de um SIGKILL enquanto espera que o kernel descubra o que há com o compartilhamento.

    
por 11.12.2010 / 16:57
0

Na verdade, o rpmlib, usado pelo yum, está capturando e ignorando o manipulador de sinais ctrl-c. Há tanta coisa pode ser feita sobre isso no nível do yum. É chato, mas não tenho certeza se vale a pena ficar todo empolgado. Versões mais recentes e mais recentes do Fedora melhoraram com sucesso o manuseio deste, até o ponto em que o yum sob o Rawhide (que se tornará o F15) faz isso para o seu caso de teste:

$ time yum list >/dev/null
^CTraceback (most recent call last):
  File "/usr/lib64/python2.7/site.py", line 553, in <module>
    main()
  File "/usr/lib64/python2.7/site.py", line 544, in main
    execsitecustomize()
  File "/usr/lib64/python2.7/site.py", line 500, in execsitecustomize
    import sitecustomize
KeyboardInterrupt

real    0m0.164s
user    0m0.081s
sys     0m0.073s

Ele ainda não permitirá que você interrompa alterações no banco de dados RPM com o SIGINT, o que é difícil de discutir.

    
por 12.12.2010 / 16:03