Ctrl + c não mata o processo

8

Procurei respostas e até agora não encontrei nada para responder à minha pergunta. Atualmente, estou efetuando login no meu servidor Ubuntu e, ao executar um processo, não consigo executar nenhuma das interrupções nele. Aqui está o meu stty -a:

user@Ubuntu1:~$ stty -a
speed 38400 baud; rows 93; columns 200; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;

Não tenho nada no meu .bashrc que mude as interrupções.

É o mesmo para todos os usuários, incluindo o root. Também tentei fazer login em locais diferentes usando terminais diferentes e sempre que esse mesmo resultado aparecer. Eu usei o ssh e o ssh -X para fazer login.

Edit: Localmente todas as minhas interrupções funcionam bem.

Atualização: Ainda estou procurando uma resposta. Meu amigo tem exatamente o mesmo problema. A questão parece muito grande: ao fazer login (no PC, Mac, Linux), o teclado não apanha essas teclas (mesmo que corretamente mapeadas).

— user700786
fonte

Qual é o resultado de Ctrl+Ve bater Ctrl+C? Você já tentou matar o processo kill -s 2 <pid_of_process>? Isso deve ser igual ao envio do sinal SIGINT para o processo. Verifique as configurações principais do emulador de terminal.

A saída está correta. Se eu fizer o seguinte Ctrl + V e Ctrl + CI, obter ^ C. Eu recebo o mesmo se pressionar Ctrl + V e, em seguida, Ctrl + Z obter ^ Z. Posso matar processos com kill se fizer isso de outro terminal. Também por isso, note localmente e em outros terminais estes comandos funcionam bem

— user700786

3

Você já tentou bater Ctrl+Cenquanto executa outro processo (por exemplo cat)? Talvez seja esse processo que ignora Ctrl+C. Ou você quer dizer que localmente no servidor Ubuntu, esse processo específico responde Ctrl+C, nesse caso, em que terminal você tentou? Que tal uma screensessão?

— Gilles 'SO- stop be evil'

Se eu executar qualquer coisa no terminal da minha máquina, as interrupções não serão encontradas. É assim que eu ssh no meu servidor que não vai pegar as interrupções. Nenhum dos processos que eu tentei pegar interrupções #

— user700786 14/02/12

Se o comando for eliminado kill -s 2(observe o -s 2que é SIGINT(o sinal normalmente enviado quando você pressiona Ctrl + C, o padrão killé SIGTERM))), então o comando não está ignorando a interrupção. Outra coisa está pegando. Quando você executa isso localmente e funciona, você está dizendo que funciona usando o mesmo terminal na máquina cliente para executar algo localmente ou executando um emulador de terminal localmente na máquina servidor? Gostaria de saber se você está usando algum emulador que está tentando imitar Ctrl + C do mundo Windows ...

— njsg

5

ctrl+ cnunca mata um programa,

Isso não é o que faz.

Há um conjunto de sinais que o padrão POSIX define; estes são usados para controlar um programa em execução.

  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
  SIGTERM      15       Term    Termination signal

- http://man7.org/linux/man-pages/man7/signal.7.html

ctrl+ cenvia o sinal 2"Interromper do teclado" para o programa que você executou em um terminal.

Depende inteiramente do programa lidar com esse sinal, ele pode fazer o que quiser sobre ele. Muitos intérpretes da linguagem de script podem lidar com isso de maneira padrão, matando o script chamado e saindo normalmente.

Se você deseja que um programa saia, especialmente de um contexto automático, o código 15 é recomendado, o killprograma pode ser usado para enviar sinais para um processo por id (pid).

kill -15 <pid>

Tanto quanto sei, o programa ainda recebe esse sinal em si e deve terminar o mais rápido possível o mais rápido possível.

No entanto, se o programa ignorar o sinal 15, e o programa persistir (e você não estiver conseguindo enviar o sinal devido a um erro de permissão)

kill -9 <pid>

O sinal 9, até onde sei, é interpretado pelo kernel (o gerenciador de tarefas e a interface de hardware). O kernel para abruptamente o processamento do programa e desaloca / libera todos os seus recursos.

— ThorSummoner
fonte

3

Aqui está um truque hardcore:

Control-Z

suspenderá seu processo e retornará o ID da tarefa desse processo

Então:

kill -9 %1

(substitua 1 pelo seu ID do trabalho).

Nota: A porcentagem é obrigatória !, caso contrário, você matará seu processo de inicialização, o que significa que você matará o kernel e todo o sistema falhará (portanto, não coloque o espaço no meio :)

— kenorb
fonte

0

Ctrl + c não mata o processo. apenas interrompe o processo atual em execução no meio. Para matar o processo, precisamos usar o comando "KILL"

— Rajeev Tarun Mavuri
fonte

7

De fato, killenvia um sinal para um processo. O sinal padrão enviado com killé TERM, o sinal enviado com ctrl+cé SIGINT.

— fmanco 11/07/12

0

Eu encontrei este post antigo no fórum sobre esse problema em particular. Parece que a sequência de interrupção padrão pode ser substituída em um arquivo de configuração separado em algum lugar.

Se você está apenas procurando matar esse processo externamente, pode usar o kill apenas cuidado, pois você deve escalar o kill, conforme descrito neste artigo sobre processos de kill, em vez de simplesmente pular para o kill extremo mais -9.

A Wikipedia é um ótimo recurso para o programa kill . Também aqui está uma lista de sinais Unix e o que eles fazem.

— jjclarkson
fonte