Linux / Comando kill: enviar sinais a um PID e verificar o resultado

kill envia um sinal a um processo identificado pelo seu PID, o identificador de processo, ou a um trabalho reconhecido pelo shell. O sinal padrão é SIGTERM, um pedido de término. O resultado depende do sinal, das permissões e de como a aplicação o trata; enviar o sinal não comprova que o processo terminou.

No Bash, kill é um comando interno do shell, embora também possa existir um executável com esse nome. Para encerrar uma aplicação, use primeiro seu procedimento normal de parada. Antes de enviar um sinal diretamente, confirme que o PID ainda identifica o processo pretendido.

Sintaxe e comando usado pelo shell

kill [-s sinal] PID ...

Use type -a kill para identificar as implementações disponíveis e help kill para consultar o comando interno do Bash. A forma curta -TERM e a forma -s TERM especificam SIGTERM explicitamente. Sem a opção de sinal, o padrão do Bash é SIGTERM.

A documentação de controle de trabalhos do Bash também descreve os identificadores de trabalho, como %1, que dependem da tabela de trabalhos daquele shell. Eles não são números de PID nem uma forma portátil de identificar um processo em outro terminal; o uso de trabalhos exige o contexto de controle de trabalhos apropriado.

Confirmar o PID antes da ação

O número 1234 abaixo é ilustrativo. Substitua-o pelo PID atual de um processo de teste seu antes de considerar o envio de qualquer sinal:

ps -p 1234 -o pid,user,stat,cmd

Na implementação ps de procps-ng para Linux, os campos permitem conferir o PID, o usuário, o estado e a linha de comando. O guia de ps e seus campos de processo explica a consulta. Verifique se nome, usuário e argumentos correspondem ao alvo; um PID antigo pode já ter sido reutilizado.

Uma nova consulta reduz o risco de usar um número desatualizado, mas não torna a sequência atômica: o processo pode terminar depois da consulta. Para serviços, a ferramenta responsável por administrá-los costuma oferecer uma operação de parada mais apropriada do que trabalhar com um PID copiado há algum tempo.

Enviar um pedido de término

Somente depois de conferir o alvo e sua autorização, a forma explícita para o PID ilustrativo é:

kill -TERM 1234

Não execute essa linha mantendo 1234 por conveniência: o número pode pertencer a outro processo. No caso bem-sucedido, kill normalmente não escreve uma mensagem. Capture seu estado de saída imediatamente com printf '%s\n' "$?", antes que outro comando o substitua, e leia eventuais mensagens de erro.

O estado do comando descreve o envio do sinal, não o término completo da aplicação. SIGTERM pode ser tratado, bloqueado ou ignorado. Uma aplicação que o trate pode precisar de tempo para fechar conexões e concluir trabalho; o sinal não garante que esses passos foram executados.

Consultar os nomes dos sinais

Para listar os sinais reconhecidos pelo Bash atual:

kill -l

Prefira nomes como TERM, INT e HUP a números memorizados quando precisar tornar a intenção clara. A numeração pode variar entre plataformas e arquiteturas. O manual de sinais do Linux distingue a ação padrão de cada sinal e o tratamento que a aplicação pode instalar.

SIGHUP não significa universalmente “recarregar configuração”: sua ação padrão é terminar, e alguns programas adotam outro tratamento documentado. SIGINT é o sinal associado à interrupção no terminal, mas enviar INT a um PID não é o mesmo que reproduzir todos os efeitos de Ctrl+C sobre um grupo de processos em primeiro plano.

Testar com um filho criado pelo próprio Bash

Esta prática usa Bash, sleep e, para as consultas de campos, ps de procps-ng em Linux. Execute-a em um Bash sem set -e. Ela cria um sleep de 30 segundos, guarda seu PID em $!, verifica que o valor é positivo e envia SIGTERM somente a esse filho. Não é necessário usar um PID fixo, nome de serviço ou privilégios administrativos.

(
  sleep 30 &
  demo_pid=$!
  case "$demo_pid" in
    ''|*[!0-9]*|0) exit 1 ;;
  esac
  sleep 0.2
  ps -p "$demo_pid" -o pid,stat,comm
  ps_before=$?
  if kill -0 "$demo_pid"; then
    kill -s TERM "$demo_pid"
    signal_status=$?
  else
    signal_status=1
  fi
  wait "$demo_pid"
  wait_status=$?
  ps -p "$demo_pid" -o pid,stat,comm
  ps_after=$?
  kill -0 "$demo_pid"
  probe_after=$?
  printf 'ps-antes=%s kill=%s wait=%s ps-depois=%s teste-final=%s\n' \
    "$ps_before" "$signal_status" "$wait_status" "$ps_after" "$probe_after"
)

Em Linux com ps de procps-ng, espera-se que a primeira consulta mostre o sleep e que a consulta depois de wait não o encontre. Se SIGTERM encerrar esse filho, o resumo esperado é ps-antes=0 kill=0 wait=143 ps-depois=1 teste-final=1. A saída pode incluir uma mensagem de término do trabalho e, no teste final de existência, uma indicação de que o processo não existe.

O wait se aplica ao filho desse Bash e permite observar seu estado de término; ele não serve para esperar qualquer PID arbitrário do sistema. O valor 143 representa 128 + 15, neste caso de término por SIGTERM. Um sleep que conclua naturalmente retorna 0. Não use set -e nessa prática, pois os estados não zero fazem parte da observação.

Na verificação realizada com Bash 5.3.9 do Git para Windows, o sinal enviado ao único sleep criado retornou 0 e wait retornou 143. O teste final com kill -0 retornou 1. Porém, o ps disponível era a implementação Cygwin e rejeitou -o nas duas consultas: o resumo real foi ps-antes=1 kill=0 wait=143 ps-depois=1 teste-final=1. Isso confirma essa experiência com o comando interno do Bash naquele ambiente, mas não valida as colunas de ps nem as permissões e o comportamento do kernel Linux.

Sinais e formas de verificação

-0 é a opção de sinal zero, não um PID de valor zero. Não a confunda com o argumento PID 0. No Linux, alvos zero ou negativos têm significados de grupo ou de conjunto de processos, conforme o manual de kill(2). Os exemplos de sinalização deste artigo usam um PID positivo individual.

Interpretar falhas e processos que continuam visíveis

Uma falha de kill -0 pode indicar que o alvo não existe ou que falta permissão para sinalizá-lo. Sucesso não comprova que o programa está saudável, responde a pedidos ou concluiu suas tarefas. No Linux, até um processo defunto, que já terminou mas ainda não foi recolhido pelo pai, pode continuar presente na tabela.

A seleção de um PID e a permissão para sinalizá-lo são questões distintas. As regras de identidade e privilégios do Linux descritas em kill(2) continuam valendo; um erro de permissão não deve ser interpretado como prova de que o processo está ausente. Confira o contexto, o usuário e a operação autorizada.

Se o processo continuar visível após SIGTERM, examine seu estado e os registros. Ele pode estar tratando o pedido, ter bloqueado ou ignorado o sinal, já estar defunto ou ter sido substituído por um novo processo iniciado por um supervisor. Compare também o PID e o início da tarefa, em vez de repetir sinais sem identificar o motivo.

SIGKILL não permite que a aplicação execute um tratador para salvar dados e limpar recursos. Ele não torna trabalho não salvo recuperável nem comprova, sozinho, que todas as consequências da interrupção foram resolvidas. Considere uma ação forçada apenas depois de conferir o alvo e o procedimento da aplicação.

Pergunta frequente

O que conferir se kill não fizer o processo desaparecer?

Confira o resultado do envio, as permissões, o estado atual e os registros do processo. SIGTERM pode estar em tratamento, bloqueado ou ignorado; um processo defunto já terminou, e um supervisor pode iniciar outro. Para serviços, use o procedimento documentado de parada e confirme o resultado antes de considerar outro sinal.