Eu tenho uma situação estranha.
Eu tenho um programa escrito em C, "A", que aceita como argumento o nome de outros executáveis, por exemplo, “B”, “C”, “D” etc. O trabalho principal de “A” é bifurcar e iniciar “B”, “C” etc, então verificar se eles falharem e, nesse caso, reiniciar o processo travado.
Além disso, o processo "A" executa um thread separado para fins de sincronização do RTC.
"A" é iniciado como /bin/sh -c A B C D etc .
Eu estou em um ambiente embarcado e estou usando um kernel personalizado derivado do Linux 4.4.57.
Agora, para o problema: acontece que às vezes meu processo "A" se torna zumbi!
Algumas observações que fiz:
/bin/sh -c , que iniciou "A" ainda está ativo; /bin/sh -c , o pai de "A" se tornará init (1), mas ainda assim, o processo permanecerá zumbi; kill -9 «pid-of-A» ; Agora, por causa de "A" respondendo a sinais e o segmento interno ainda em execução, esse processo de zumbi está me enlouquecendo.
O que explica tal comportamento? Pode ser algo relacionado à configuração de compilação do kernel?
EDITAR : Eu olhei melhor no código e descobri que “A” é iniciado como um daemon com o seguinte comando:
start-stop-daemon -b --start --quiet --pidfile /var/run/A.pid --background --exec /bin/sh -- -c "A B C D > /var/log/log 2>&1"
UPDATE : Eu consegui replicar o mesmo comportamento exato chamando pthread_exit (). O problema é que não consigo encontrar nenhuma referência a phread_exit na fonte original. Existe alguma outra maneira que o tópico principal pare de deixar vivo todos os outros?
Eu encontrei o problema e a solução do meu problema olhando para o dmesg: Eu descobri que havia um "erro interno: Oops: 817 [# 1] ARM" causado por uma função de kernel personalizada em um arquivo proc. O arquivo proc foi lido pelo thread principal do processo tornando-se zumbi, e algumas vezes essa operação fez com que o thread principal morresse ... Isso é exatamente semelhante à resposta de @muru. Eu consertei a função e agora o processo não morre mais. Obrigado de qualquer maneira a todos.
Um processo zumbi é um processo que foi concluído, mas ainda tem uma entrada na tabela de processos, porque, por exemplo, seus filhos ainda estão vivos (veja Wikipedia ).
Então se, como você diz, nenhum de B, C e D está morto, e A termina a execução, ele se tornará um zumbi até que todos os B, C e D também terminem a execução.
Este é um comportamento normal.
Então, isso parece um bug em A: Ele não deve morrer enquanto seus filhos ainda estiverem vivos, porque ele deveria monitorar os filhos. Corrigir o bug em A e não se preocupe em se tornar um zumbi.
Se você estiver usando pthread_exit() na função main() , esta postagem SO sugere que o segmento principal poderia entrar em um estado de zumbi, mas outros segmentos continuam em execução. Como chamar pthread_exit() em main() é perfeitamente legal, suponho que este seja um estado normal de coisas e que esse ser morto-vivo específico é inofensivo. Você pode ignorá-lo ou aguardar outros tópicos em main() em vez de usar pthread_exit() .