Estou usando o Ubuntu 14.04 e estou enfrentando esse comportamento que não consigo entender:

1. Execute o yescomando (no shell padrão: Bash )
2. Digite CtrlZpara pararyes
3. Corra jobs. Resultado:
   [1]+ Stopped yes
4. Corra kill -9 %1para parar yes. Resultado:
   [1]+ Stopped yes
5. Corra jobs. Resultado:
   [1]+ Stopped yes

Isso ocorre no Ubuntu 3.16.0-30-genericrodando em uma máquina virtual paralela.

Por que meu kill -9comando não encerrou o comando yes ? Eu pensei que SIGKILL não pode ser pego ou ignorado? E como posso terminar o comando yes ?

Os sinais estão bloqueados para processos suspensos. Em um terminal:

$ yes
...
y
y
^Zy

[1]+  Stopped                 yes

Em um segundo terminal:

$ killall yes

No primeiro terminal:

$ jobs
[1]+  Stopped                 yes

$ fg
yes
Terminated

No entanto, SIGKILLnão pode ser bloqueado. Fazer a mesma coisa com killall -9 yeso segundo terminal fornece isso imediatamente no yesterminal:

[1]+  Killed                  yes

Consequentemente, se kill -9 %1não encerrar o processo imediatamente, você bashnão estará enviando o sinal até fgo processo ou você descobriu um bug no kernel.

Não entre em pânico.

Não há nada estranho acontecendo. Não há bug do kernel aqui. Esse é um comportamento perfeitamente normal do shell Bourne Again e de um sistema operacional multitarefa.

É importante lembrar que um processo se mata , mesmo em resposta a SIGKILL. O que está acontecendo aqui é que o shell Bourne Again está lidando com as coisas antes do processo que ele acabou de dizer para se matar.

Considere o que acontece a partir do ponto em yesque foi interrompido SIGTSTPe você acabou de executar o killcomando com o shell Bourne Again:

1. O shell envia SIGKILLpara o yesprocesso.
2. Em paralelo :
   1. O yesprocesso está programado para ser executado e se mata imediatamente.
   2. O shell Bourne Again continua, emitindo outro prompt.

O motivo pelo qual você está vendo uma coisa e outras pessoas estão vendo outra é uma corrida simples entre dois processos prontos para execução, cujo vencedor é inteiramente o que varia de máquina para máquina e ao longo do tempo. A carga do sistema faz a diferença, assim como o fato de sua CPU ser virtual.

No caso interessante, os detalhes da etapa 2 são os seguintes:

1. O shell Bourne Again continua.
2. Como parte dos elementos internos do killcomando interno, ele marca a entrada em sua tabela de tarefas como necessitando de uma mensagem de notificação impressa no próximo ponto disponível.
3. Ele termina o killcomando e, pouco antes de imprimir, o prompt verifica novamente se deve imprimir mensagens de notificação sobre algum trabalho.
4. O yesprocesso ainda não teve a chance de se matar, portanto, no que diz respeito ao shell, o trabalho ainda está no estado parado. Portanto, o shell imprime uma linha de status de trabalho "Interrompido" para esse trabalho e redefine seu sinalizador de notificação pendente.
5. O yesprocesso é agendado e se mata.
6. O kernel informa ao shell, que está ocupado executando seu editor de linha de comando, que o processo se matou. O shell observa a alteração no status e sinaliza o trabalho como notificação pendente novamente.
7. Basta pressionar enterpara percorrer novamente a impressão rápida, dando ao shell a chance de imprimir o novo status do trabalho.

Os pontos importantes são:

• Processos se matam. SIGKILLnão é mágico. Os processos verificam sinais pendentes ao retornar ao modo de aplicativo a partir do modo kernel, o que ocorre no final das falhas da página, interrupções (não aninhadas) e chamadas do sistema. A única coisa especial é que o kernel não permite que a ação em resposta SIGKILLseja outra coisa senão suicídio imediato e incondicional, sem retorno ao modo de aplicativo. É importante ressaltar que os processos precisam estar fazendo transições do modo kernel para aplicativo e devem ser agendados para serem executados para responder a sinais.
• Uma CPU virtual é apenas um encadeamento em um sistema operacional host. Não há garantia de que o host tenha agendado a execução da CPU virtual. Os sistemas operacionais host também não são mágicos.
• As mensagens de notificação não são impressas quando as alterações no estado do trabalho acontecem (a menos que você use set -o notify). Eles são impressos quando, em seguida, o shell atingir um ponto em seu ciclo de execução que verifica se há alguma notificação pendente.
• O sinalizador de notificação pendente está sendo definido duas vezes, uma vez kille uma vez pelo SIGCHLDmanipulador de sinal. Isso significa que é possível ver duas mensagens se o shell estiver executando antes do yesprocesso ser remarcado para se matar; uma mensagem "Parada" e uma mensagem "Morto".
• Obviamente, o /bin/killprograma não tem acesso à tabela de tarefas internas do shell; então você não verá esse comportamento com /bin/kill. O sinalizador pendente de notificação é definido apenas uma vez, pelo SIGCHLDmanipulador.
• Pelo mesmo motivo, você não verá esse comportamento se killo yesprocesso for de outro shell.

Algo descolado pode estar acontecendo no seu sistema; no meu, sua receita funciona muito bem com e sem o -9:

> yes
...
^Z
[1]+  Stopped                 yes
> jobs
[1]+  Stopped                 yes
> kill %1
[1]+  Killed                  yes
> jobs
> 

Receba o pid com jobs -pe tente matá-lo como root.

O que você está observando é um bug nesta versão do bash.

kill -9 %1mata o trabalho imediatamente. Você pode observar isso com ps. Você pode rastrear o processo bash para ver quando a killchamada do sistema é chamada e rastrear o subprocesso para ver quando recebe e processa os sinais. Mais interessante, você pode ver o que está acontecendo com o processo.

bash-4.3$ sleep 9999
^Z
[1]+  Stopped                 sleep 9999
bash-4.3$ kill -9 %1

[1]+  Stopped                 sleep 9999
bash-4.3$ jobs
[1]+  Stopped                 sleep 9999
bash-4.3$ jobs -l
[1]+  3083 Stopped                 sleep 9999
bash-4.3$ 

Em outro terminal:

% ps 3083
  PID TTY      STAT   TIME COMMAND
 3083 pts/4    Z      0:00 [sleep] <defunct>

O subprocesso é um zumbi . Está morto: tudo o que resta é uma entrada na tabela de processos (mas não há memória, código, arquivos abertos etc.). A entrada é deixada em aberto até que seu pai ou mãe notifique e recupere seu status de saída chamando a waitchamada de sistema ou um de seus irmãos .

Um shell interativo deve verificar se há filhos mortos e colhê-los antes de imprimir um prompt (a menos que configurado de outra forma). Esta versão do bash falha ao fazê-lo em algumas circunstâncias:

bash-4.3$ jobs -l
[1]+  3083 Stopped                 sleep 9999
bash-4.3$ true
bash-4.3$ /bin/true
[1]+  Killed                  sleep 9999

Você pode esperar que o bash relate "Killed" assim que imprimir o prompt após o killcomando, mas isso não é garantido, porque há uma condição de corrida. Os sinais são entregues de forma assíncrona: a killchamada do sistema retorna assim que o kernel descobre para quais processos entregar o sinal, sem esperar que ele seja realmente entregue. É possível, e acontece na prática, que o bash tenha tempo para verificar o status de seu subprocesso, descobrir que ele ainda não está morto ( wait4não relata nenhuma morte infantil) e imprimir que o processo ainda está parado. O que há de errado é que, antes do próximo prompt, o sinal foi entregue ( psrelata que o processo está morto), mas o bash ainda não foi chamadowait4(podemos ver isso não apenas porque ele ainda relata o trabalho como "Parado", mas porque o zumbi ainda está presente na tabela de processos). De fato, o bash só colhe o zumbi na próxima vez que ele precisar chamar wait4, quando executa algum outro comando externo.

O bug é intermitente e eu não pude reproduzi-lo enquanto o bash é rastreado (presumivelmente porque é uma condição de corrida em que o bash precisa reagir rapidamente). Se o sinal é entregue antes das verificações do bash, tudo acontece como esperado.