Linux / Comando killall: enviar sinais a processos pelo nome

No Linux, killall da implementação psmisc envia um sinal aos processos que executam os comandos com os nomes indicados. O sinal padrão é SIGTERM, um pedido de término. Se várias instâncias corresponderem ao nome, todas podem ser atingidas; confira os candidatos antes da ação.

Psmisc é um conjunto de pequenos utilitários que consultam informações de processos em /proc. Este artigo trata dessa implementação para Linux. Não transfira os comandos automaticamente para outro Unix: o nome killall pode designar uma operação diferente.

Sintaxe e implementação

killall [opções] nome ...

Confira man killall no sistema em que pretende usá-lo. Depois de confirmar que se trata de psmisc, killall -V mostra a versão e killall -l lista os sinais conhecidos. A disponibilidade de um programa chamado killall, sozinha, não identifica sua implementação.

O manual de killall do projeto psmisc documenta a seleção pelo nome e a opção -r para interpretar o nome como expressão regular estendida. A pesquisa por expressão regular não é o modo padrão dessa ferramenta.

Consultar processos com o mesmo nome

myworker é um nome ilustrativo de processo de teste. Antes de considerar qualquer sinal, consulte os candidatos:

pgrep -a -x myworker

A saída mostra identificadores de processo, os PIDs, e linhas de comando. Confira todas as linhas, não apenas a primeira. Se a consulta revelar várias instâncias, uma ação pelo nome poderá afetar mais de uma delas. O guia de pgrep e seus critérios de pesquisa explica a consulta.

Essa consulta não é uma simulação interna de killall: pgrep usa expressões regulares por padrão, mesmo com -x. Para nomes simples como myworker, ela ajuda a conferir o nome inteiro; nomes com metacaracteres, nomes longos ou critérios adicionais exigem cuidado. Confira usuário, argumentos e PID também com ps quando precisar distinguir as instâncias.

Enviar SIGTERM pelo nome

Somente quando todas as correspondências forem seus processos de teste autorizados, a forma explícita é:

killall -TERM myworker

Na implementação psmisc, -TERM especifica SIGTERM; sem uma opção de sinal, ele também é o padrão. O comando normalmente não mostra uma lista de PIDs no caso bem-sucedido. Ausência de texto não comprova que cada aplicação terminou ou concluiu sua limpeza.

O guia de kill e interpretação dos sinais explica por que enviar SIGTERM e observar o término são etapas diferentes. Uma aplicação pode tratar, bloquear ou ignorar esse sinal; o tempo para parar depende do programa.

Restringir nome e usuário

Para limitar o nome myworker aos processos pertencentes à conta alice:

killall -u alice myworker

Substitua alice por uma conta existente e confirme que todos os alvos correspondem à operação autorizada. Selecionar um usuário não muda a identidade de quem executa o comando nem concede novas permissões. O nome continua sendo parte essencial da restrição desse exemplo.

No manual de psmisc, nomes são opcionais quando se usa -u. Portanto, retirar myworker não significa apenas “tentar novamente”: pode ampliar a ação aos processos daquele usuário. Uma consulta de pgrep com usuário pode ajudar a investigar, mas os critérios das duas ferramentas não devem ser considerados idênticos sem conferir a implementação e o campo usado.

Prática com duas instâncias de um executável de teste

O exemplo completo exige Linux, Bash, killall de psmisc, ps de procps-ng e os utilitários cp, mktemp e sleep. Execute-o numa pasta gravável, em um Bash sem set -e. Ele cria uma pasta nova, copia o executável sleep como demo-worker e inicia duas esperas de 30 segundos.

A ação usa o caminho absoluto do arquivo recém-criado. No modo sem -r de psmisc, um nome contendo / seleciona processos que executam aquele arquivo, em vez de apenas comparar o nome curto. Isso limita esta prática à cópia exclusiva que ela acabou de criar. Não substitua o caminho por um nome amplo nem use um interpretador ou script como se tivesse a mesma identidade de executável.

(
  for tool in killall ps cp mktemp sleep; do
    command -v "$tool" >/dev/null || exit 1
  done
  sleep_bin=$(type -P sleep) || exit 1
  demo_dir=$(mktemp -d "$PWD/killall-demo.XXXXXX") || exit 1
  cp -- "$sleep_bin" "$demo_dir/demo-worker" || exit 1
  "$demo_dir/demo-worker" 30 &
  demo_one=$!
  "$demo_dir/demo-worker" 30 &
  demo_two=$!
  sleep 0.2
  ps -p "$demo_one,$demo_two" -o pid,user,stat,comm,args

  if kill -0 "$demo_one" && kill -0 "$demo_two"; then
    killall -v -s TERM "$demo_dir/demo-worker"
    signal_status=$?
  else
    signal_status=1
  fi
  wait "$demo_one"
  first_status=$?
  wait "$demo_two"
  second_status=$?
  printf 'killall=%s primeiro=%s segundo=%s\n' \
    "$signal_status" "$first_status" "$second_status"
)

A consulta inicial deve mostrar os dois filhos e seus argumentos. Se SIGTERM encerrar ambos antes de completarem a espera natural, o resumo esperado no Bash é killall=0 primeiro=143 segundo=143. Esse é o resultado previsto para a prática, não uma saída medida nesta verificação. -v pode mostrar os alvos sinalizados e o shell pode mostrar mensagens de término.

O bloco não usa -w: cada wait recolhe o estado de um filho criado pelo próprio Bash. Um estado 143 representa término por SIGTERM nesse caso; 0 pode indicar que o sleep terminou naturalmente. Os estados são guardados separadamente antes de imprimir o resumo. A pasta de teste fica disponível para inspeção.

Na verificação disponível, Bash 5.3.9 do Git para Windows não encontrou killall nem pgrep. Os quatro blocos originais e o exemplo completo passaram pela análise de sintaxe; não foram executados killall, seleção de processos Linux, cópia de executáveis ou envio de sinais para esta prática. Essa análise não confirma o funcionamento de psmisc em Linux.

Opções para escolher e acompanhar a ação

Não transporte letras de opções entre ferramentas sem conferir o significado. Em killall de psmisc, -e trata correspondências exatas de nomes muito longos e pode pular entradas cujo nome completo esteja indisponível; não significa exibir alvos como a opção -e de pkill. O manual descreve casos de nomes com mais de 15 caracteres em que a comparação pode ficar limitada ao prefixo; usar -e reduz esse tipo de correspondência incerta.

Resultado, espera e serviços

Na forma com nomes, o manual de psmisc define estado 0 quando há sucesso para pelo menos um processo de cada comando listado; caso contrário, retorna um estado não zero. Isso não demonstra que todas as instâncias terminaram. Confira o estado imediatamente após killall, as mensagens e uma nova consulta aos processos antes de concluir que a operação terminou.

-w verifica aproximadamente uma vez por segundo se os processos ainda existem e pode esperar indefinidamente se o sinal for ignorado, não tiver efeito ou se o processo permanecer defunto. Um processo defunto já terminou a execução, mas ainda aguarda que o pai recolha seu estado. -w não é uma opção de tempo limite nem uma garantia de parada rápida.

O manual também informa que -w não distingue um PID que desapareceu e foi reutilizado entre duas verificações. Nomes podem mudar e um supervisor pode iniciar novas instâncias. Para um serviço administrado por systemd, uma operação de parada da unidade correta costuma ser mais apropriada; use o procedimento documentado do gerenciador presente naquele sistema, em vez de pressupor que todo Linux usa o mesmo gerenciador.

Se precisar apenas de um processo específico, identifique seu PID e reavalie se uma ação pelo nome é adequada. Não use SIGKILL como uma substituição automática por falta de resposta: esse sinal impede o tratamento de limpeza da aplicação, e o trabalho não salvo pode ser perdido.

Pergunta frequente

Killall encerra todos os processos do sistema?

Na implementação Linux psmisc, a forma com nomes seleciona os comandos indicados, podendo atingir várias instâncias. As opções podem ampliar ou restringir essa seleção; por exemplo, -u permite omitir nomes. Outras implementações Unix podem ter outro significado, por isso confirme o manual antes de executar.

Documentação

O manual de killall publicado pelo Debian detalha nomes longos, seleção por arquivo e limites de espera. Compare essas condições com a versão instalada antes de transportar uma rotina de sinalização.