Mais cedo ou mais tarde, quem administra sistemas Linux tem de fazer uma pergunta desconfortável: como paro isto? Um processo que enlouqueceu e come 100% de CPU, um serviço que reinicia em ciclo, ou — no pior dos casos — um binário estranho que não devia estar a correr. A resposta instintiva costuma ser um kill -9 rápido. E é quase sempre a resposta errada.
Neste artigo separamos duas ferramentas que trabalham em camadas diferentes: o kill, que envia sinais a processos, e o systemctl, que gere serviços através do systemd. Perceber quando usar cada um — e por que ordem — é a diferença entre resolver um problema e piorá-lo, sobretudo durante uma resposta a incidentes.
O que faz o kill
Apesar do nome, o kill não «mata» nada diretamente: envia um sinal a um processo, identificado pelo seu PID. É depois o processo (ou o núcleo) que decide o que fazer com esse sinal. Há dezenas de sinais; na prática do dia a dia interessam meia dúzia.
kill [-SINAL] PID
kill -l # lista todos os sinais disponíveisO sinal por omissão é o SIGTERM (15): um pedido educado de término. O processo recebe-o, pode fechar ficheiros, gravar o estado e sair de forma ordenada. A alternativa violenta é o SIGKILL (9), que não passa pelo processo — é o núcleo que o remove de imediato, sem hipótese de limpeza. Por isso a regra é simples: tente sempre o 15 antes do 9.
Os sinais que interessam
SIGTERM, SIGKILL e SIGHUP
kill PIDoukill -15 PID— envia SIGTERM. É o ponto de partida para terminar qualquer processo de forma limpa.kill -9 PID— envia SIGKILL. Incapturável e imediato, mas sem limpeza: pode deixar ficheiros a meio, sockets pendurados ou dados por gravar. Último recurso.kill -HUP PID— envia SIGHUP. Historicamente significava «a linha caiu», mas muitos serviços reinterpretam-no como «relê a configuração». Umkill -HUPno processo principal do servidor web, por exemplo, aplica configuração nova sem derrubar o serviço.kill -0 PID— não envia sinal nenhum; serve apenas para testar se o processo existe e pode ser sinalizado. Muito usado em scripts.
Sinalizar por nome: killall e pkill
Nem sempre sabemos o PID. Duas ferramentas sinalizam processos por outros critérios:
killall NOME— envia um sinal (SIGTERM por omissão) a todos os processos com um dado nome. Útil, mas cego: apanha tudo o que se chame assim.pkillepgrep— selecionam por padrão, por utilizador (-u), por sessão e mais.pkill -u www-datatermina todos os processos desse utilizador — poderoso e perigoso na mesma medida.
# Terminar um processo pelo PID, de forma limpa
kill 2087
# Recarregar a configuração sem reiniciar
kill -HUP 1204
# Só em último recurso, quando o processo ignora o SIGTERM
kill -9 2087Onde o kill falha: os serviços do systemd
Aqui está a armadilha que apanha muita gente. Num sistema moderno com systemd, os serviços têm normalmente uma diretiva Restart=. Se um serviço estiver configurado com Restart=always e nós matarmos o seu processo — com 15 ou com 9, tanto faz — o systemd deteta a saída e volta a lançá-lo de imediato, com um novo PID. Matar o processo não trava o serviço. Para isso, temos de subir uma camada.
Gerir serviços com systemctl
O systemctl é a interface de controlo do systemd. Em vez de mexer em processos soltos, atua sobre units — normalmente serviços (.service). A forma geral é intuitiva:
systemctl COMANDO UNITsystemctl status UNIT— mostra o estado (active, inactive, failed), o Main PID, oExecStarte as últimas linhas de log. É por aqui que se começa sempre: entender antes de agir.systemctl start/stop UNIT— arranca ou pára o serviço agora. Umstopdeliberado anula a lógica deRestart: o systemd não o volta a levantar.systemctl restart/reload UNIT— reinicia por completo, ou relê a configuração sem reiniciar (quando o serviço o suporta).systemctl enable/disable UNIT— liga ou desliga o arranque automático no boot. Não afeta o estado atual, só o próximo arranque.systemctl enable --now/disable --now— combinam as duas ações:enable --nowativa e arranca;disable --nowdesativa e pára, num só passo.systemctl list-units --failed— lista as units em estadofailed. Excelente para uma triagem rápida do que está partido.systemctl daemon-reload— obriga o systemd a reler os ficheiros de unit depois de os editarmos. Sem isto, o systemd continua a usar a definição antiga em memória.
A distinção entre parar e desativar é essencial: stop pára o serviço agora, mas ao próximo arranque ele volta se estiver enabled. Para o remover de vez, é preciso disable — de preferência com --now, para as duas coisas de uma vez.
kill e systemctl em cibersegurança
Conter sem destruir evidência. Numa resposta a incidentes, o reflexo de disparar kill -9 contra um processo suspeito é contraproducente. O SIGKILL apaga o estado do processo — memória, ficheiros abertos, ligações — que poderia ser recolhido para análise forense. A abordagem correta é documentar primeiro (que processo é, que ficheiro executa, que sockets tem abertos) e só depois conter, preferindo o stop controlado ao sinal violento.
Serviços como mecanismo de persistência. Uma técnica clássica de persistência é registar um serviço systemd que relança o malware sempre que este morre ou a máquina reinicia. É por isso que matar o processo não chega: com Restart=always, ele renasce. A contenção real faz-se pela ordem systemctl status (perceber o que é e de onde arranca) → stop (parar) → disable (impedir que volte). Um ExecStart a apontar para /tmp ou para um caminho oculto é um forte indicador de comprometimento.
Sinais como comunicação entre processos. Os sinais não servem só para terminar: são um mecanismo de IPC. O SIGHUP para recarregar configuração, o SIGUSR1/SIGUSR2 para acionar comportamentos definidos pela aplicação (rodar logs, ativar depuração). Saber isto evita reinícios desnecessários de serviços em produção.
Experimente no simulador interativo
A simulação abaixo recria uma máquina comprometida: um processo /tmp/.x/kworkerd a devorar a CPU, mantido vivo por um serviço sysupdate com Restart=always. No painel esquerdo vê os processos e os serviços com o respetivo estado; no terminal à direita, o efeito de cada comando. Clique nas ações — kill, kill -9, kill -HUP, systemctl status/stop/disable — e repare como o estado da máquina muda. Use Demonstrar tudo para seguir a sequência guiada de resposta ao incidente, ou navegue passo a passo com Anterior e Seguinte. O botão Repor estado devolve a máquina à situação inicial.
Erros comuns e boas práticas
- Começar pelo
kill -9: retira ao processo qualquer hipótese de limpeza e destrói estado útil para análise. Tente sempre o SIGTERM primeiro. - Matar o processo de um serviço gerido pelo systemd: com
Restart=alwaysele volta com novo PID. Usesystemctl stop, nãokill. - Confundir
stopcomdisable: parar não impede o arranque no próximo boot. Para conter de vez, combine comdisable(ou usedisable --now). - Abusar do
pkill -u: termina todos os processos de um utilizador, incluindo serviços legítimos. É um martelo, não um bisturi. - Esquecer o
daemon-reload: depois de editar um ficheiro de unit, o systemd continua a usar a versão antiga até ser avisado. - Trabalhar por PID em ambientes dinâmicos: os PID mudam a cada arranque do processo. Sempre que possível, atue ao nível do serviço, que é estável.
Conclusão
O kill e o systemctl resolvem o mesmo objetivo aparente — «parar isto» — mas em camadas diferentes, e trocá-las é fonte de erros. A regra que fica: sinais para processos avulsos e recargas de configuração; systemctl para tudo o que seja um serviço. E, perante o suspeito, a ordem certa é sempre perceber, parar e impedir que volte. Se administra utilizadores para além de processos, veja também o nosso artigo sobre o useradd.
Quer levar estas competências mais longe, ou precisa de apoio especializado em resposta a incidentes e administração de sistemas? Conheça os serviços de formação e consultoria da HJFR no nosso catálogo de serviços — desenhamos percursos práticos para equipas técnicas e programas à medida para empresas.
Este artigo faz parte da série «Comandos Linux, um a um» do blog HJFR — fique atento aos próximos comandos.