Quando eu costumava killall -9 namematar um programa, o estado se tornava zumbi. Alguns minutos depois, parou realmente. Então, o que está acontecendo durante esses minutos?
Quando eu costumava killall -9 namematar um programa, o estado se tornava zumbi. Alguns minutos depois, parou realmente. Então, o que está acontecendo durante esses minutos?
Respostas:
Na verdade, o programa nunca recebe o sinal SIGKILL, pois o SIGKILL é completamente tratado pelo sistema operacional / kernel.
Quando o SIGKILL para um processo específico é enviado, o agendador do kernel para imediatamente, dando a esse processo mais tempo de CPU para executar o código do espaço do usuário. Se o processo tiver algum encadeamento executando o código do espaço do usuário em outras CPUs / núcleos no momento em que o planejador tomar essa decisão, esses encadeamentos também serão interrompidos. (Nos sistemas de núcleo único, isso era muito mais simples: se o único núcleo da CPU no sistema estava executando o agendador, por definição, não estava executando o processo ao mesmo tempo!)
Se o processo / encadeamento estiver executando o código do kernel (por exemplo, uma chamada do sistema ou uma operação de E / S associada a um arquivo mapeado na memória) no momento do SIGKILL, fica um pouco mais complicado: apenas algumas chamadas do sistema são interrompíveis, portanto, o O kernel marca internamente o processo como estando em um estado "morto" especial até que as chamadas do sistema ou operações de E / S sejam resolvidas. O tempo da CPU para resolvê-los será agendado como de costume. Chamadas de sistema interrompidas ou operações de E / S verificarão se o processo que as chamou está morrendo em qualquer ponto de parada adequado e sairão mais cedo nesse caso. Operações ininterruptas serão concluídas e verificarão o estado "morrendo" pouco antes de retornar ao código de espaço do usuário.
Depois que qualquer rotina do kernel em processo é resolvida, o estado do processo é alterado de "morto" para "morto" e o kernel começa a limpá-lo, semelhante a quando um programa sai normalmente. Depois que a limpeza for concluída, um código de resultado maior que 128 será atribuído (para indicar que o processo foi interrompido por um sinal; veja esta resposta para detalhes confusos ), e o processo passará para o estado "zumbi" . O pai do processo morto será notificado com um sinal SIGCHLD.
Como resultado, o próprio processo nunca terá a chance de realmente processar as informações que recebeu um SIGKILL.
Quando um processo está no estado "zumbi", significa que o processo já está morto, mas seu processo pai ainda não o reconheceu lendo o código de saída do processo morto usando a wait(2)chamada do sistema. Basicamente, o único recurso que um processo zumbi está consumindo mais é um espaço na tabela de processos que contém seu PID, o código de saída e algumas outras "estatísticas vitais" do processo no momento de sua morte.
Se o processo pai morrer antes de seus filhos, os processos filhos órfãos serão adotados automaticamente pelo PID # 1, que tem um dever especial de continuar ligando wait(2)para que qualquer processo órfão não fique como zumbi.
Se levar vários minutos para que um processo zumbi seja resolvido, isso sugere que o processo pai do zumbi está lutando ou não está fazendo seu trabalho corretamente.
Há uma descrição explícita sobre o que fazer em caso de problemas com zumbis em sistemas operacionais semelhantes ao Unix: "Você não pode fazer nada pelos próprios zumbis, pois eles já estão mortos. Em vez disso, mate o malvado mestre de zumbis! " (ou seja, o processo pai dos zumbis problemáticos)
ps: 'S' é para E / S espera que o kernel possa cancelar para entregar um sinal e 'D' para aqueles que não pode.