Como matar processos zumbis no Linux

Programas mal escritos ou com mau desempenho podem deixar processos zumbis à espreita dentro do seu computador Linux. Descubra como os zumbis são criados e como você pode finalmente colocá-los para descansar.

Como os estados de processo funcionam no Linux

O Linux, é claro, precisa acompanhar todos os aplicativos e daemons em execução no seu computador. Uma das maneiras de fazer isso é mantendo a tabela de processos. Esta é uma lista de estruturas na memória do kernel. Cada processo tem uma entrada nesta lista que contém algumas informações sobre ele.

Não há muito em cada uma das estruturas da tabela de processos. Eles contêm o ID do processo, alguns outros itens de dados e um ponteiro para o bloco de controle do processo (PCB) desse processo.

É o PCB que contém os muitos detalhes que o Linux precisa pesquisar ou definir para cada processo. O PCB também é atualizado à medida que um processo é criado, dado o tempo de processamento, e finalmente destruído.

O PCB do Linux contém mais de 95 campos. Ele é definido como uma estrutura chamada task_struct.h e tem mais de 700 linhas. O PCB contém os seguintes tipos de informações:

• Estado do processo : Os estados são descritos abaixo.
• Número do Processo : Seu identificador exclusivo dentro do sistema operacional.
• Contador de Programas : Quando este processo receber o próximo acesso à CPU, o sistema usará este endereço para encontrar a próxima instrução do processo que deve ser executada.
• Registers : A lista de registradores de CPU usados ​​por este processo. A lista pode conter acumuladores, registradores de índice e ponteiros de pilha.
• Lista de Arquivos Abertos : Arquivos associados a este processo.
• Informações de agendamento de CPU : Usado para determinar com que frequência e por quanto tempo o tempo de processamento da CPU é concedido a esse processo. A prioridade do processo, ponteiros para filas de agendamento e outros parâmetros de agendamento devem ser registrados no PCB.
• Informações de gerenciamento de memória : detalhes sobre a memória que este processo está usando, como os endereços inicial e final da memória do processo e ponteiros para as páginas de memória.
• Informações de status de E/S : Quaisquer dispositivos de entrada ou saída usados ​​pelo processo.

O “Estado do Processo” pode ser qualquer um dos seguintes:

• R: Um processo em execução ou executável. Executando o que significa que está recebendo ciclos de CPU e executando. Um processo executável está pronto para ser executado e aguardando um slot de CPU.
• S: Um processo adormecido. O processo está aguardando a conclusão de uma ação, como uma operação de entrada ou saída, ou que um recurso fique disponível.
• D: O processo está em um estado de sono ininterrupto. Ele está usando uma chamada de sistema de bloqueio e não pode continuar até que as chamadas de sistema sejam concluídas. Ao contrário do estado “Sleep”, um processo neste estado não responderá aos sinais até que a chamada do sistema seja concluída e a execução tenha retornado ao processo.
• T: O processo foi finalizado (parado) porque recebeu o sinal SIGSTOP . Ele responderá apenas aos sinais SIGKILL ou SIGCONT , que matam o processo ou o instruem a continuar, respectivamente. Isso é o que está acontecendo quando você troca de tarefas de primeiro plano ( fg ) para segundo plano ( bg) .
• Z: Um processo Zumbi. Quando um processo é concluído, ele não desaparece simplesmente. Ele libera qualquer memória que esteja usando e se remove da memória, mas sua entrada na tabela de processos e PCB permanecem. Seu estado é definido como EXIT_ZOMBIE e seu processo pai é notificado (pelo sinal SIGCHLD ) que o processo filho foi concluído.

No estado Zombie, o processo pai chama uma das famílias de funções wait() quando o processo filho é criado. Em seguida, ele aguarda uma mudança de estado no processo filho. O processo filho foi interrompido, continuado ou morto por um sinal? Ele terminou executando a conclusão natural de seu código?

Se a mudança de estado for uma que significa que o processo filho parou de ser executado, seu código de saída será lido. Em seguida, o PCB do filho é destruído e sua entrada na tabela de processos é removida. Idealmente, tudo isso acontece em um piscar de olhos, e os processos no estado zumbi não existem por muito tempo.

RELACIONADO: Como executar e controlar processos em segundo plano no Linux

O que causa processos zumbis no Linux?

Um processo pai mal escrito pode não chamar a função wait() quando o processo filho é criado. Isso significa que nada está observando mudanças de estado no processo filho e o sinal SIGCHLD será ignorado. Ou talvez outro aplicativo esteja afetando a execução do processo pai, seja devido à má programação ou intenção maliciosa.

No entanto, se o processo pai não estiver observando as alterações de estado no processo filho, a manutenção adequada do sistema não ocorrerá. O PCB e a entrada na tabela de processos não serão removidos quando o processo filho terminar. Isso resulta no estado zumbi nunca sendo removido do PCB.

Os zumbis usam um pouco de memória, mas geralmente não representam um problema. A entrada na tabela de processos é pequena, mas, até que seja liberada, o ID do processo não pode ser reutilizado. Em um sistema operacional de 64 bits, é improvável que isso cause problemas porque o PCB é muito maior que a entrada da tabela de processos.

Um grande número de zumbis poderia, concebivelmente, afetar a quantidade de memória livre para outros processos. Se você tem tantos zumbis, porém, você tem um problema sério com o aplicativo pai ou um bug do sistema operacional.

Como remover processos zumbis

Você não pode matar um processo zumbi porque ele já está morto. Ele não responderá a nenhum sinal porque foi removido da memória - não há para onde enviar um sinal SIGKILL . Você pode tentar enviar o sinal SIGCHLD para o processo pai, mas se não funcionou quando o processo filho terminou, é improvável que funcione agora também.

A única solução confiável é matar o processo pai. Quando é finalizado, seus processos filhos são herdados pelo processo init , que é o primeiro processo a ser executado em um sistema Linux (seu ID de processo é 1).

O processo init realiza regularmente a limpeza necessária dos zumbis, portanto, para matá-los, basta matar o processo que os criou. O comando top é uma maneira conveniente de ver se você tem algum zumbi.

Digite o seguinte:

 principal 

Este sistema possui oito processos zumbis. Podemos listá-los usando o comando ps e canalizando-o para egrep . Novamente, os processos zumbis têm um sinalizador de estado “Z”, e você normalmente também verá “defunct”.

Digite o seguinte:

 ps aux | egrep "Z|defunto" 

Os processos zumbis são listados.

Essa é uma maneira mais simples de descobrir os IDs de processo de zumbis do que rolar para frente e para trás no top . Também vemos que um aplicativo chamado “badprg” gerou esses zumbis.

O ID do processo do primeiro zumbi é 7641, mas precisamos encontrar o ID do processo de seu processo pai. Podemos fazer isso usando ps novamente. Usaremos a opção de saída ( -o ) para dizer ao ps para exibir apenas o ID do processo do pai e, em seguida, passá-lo com o ppid= .

O processo que queremos encontrar será indicado usando a opção -p (processo) e, em seguida, passando o ID do processo do zumbi.

Portanto, digitamos o seguinte comando para pesquisar as informações do processo 7641, mas ele relatará apenas o ID do processo pai:

 ps -o ppid= -p 7641 

Fomos informados de que o ID do processo pai é 7636. Agora podemos fazer referência cruzada usando ps mais uma vez.

Vemos que isso corresponde ao nome do processo pai anterior. Para matar o processo pai, use a opção SIGKILL com o comando kill da seguinte forma:

 matar -SIGKILL 7636

Dependendo do proprietário do processo pai, você também pode precisar usar sudo .

Zumbis não são assustadores…

… a menos que eles estejam em uma horda enorme. Alguns não são nada para se preocupar e uma simples reinicialização irá eliminá-los.

No entanto, se você perceber que um aplicativo ou processo está sempre gerando zumbis, isso é algo que você deve analisar. É mais provável que seja apenas um programa escrito de forma descuidada e, nesse caso, talvez haja uma versão atualizada que limpa adequadamente após seus processos filhos.