Existe uma maneira de identificar qual processo se transforma em processo Zombie?

Navegue suas respostas
2

Um dos servidores do Ubuntu tem 82 processos zumbis. Todos os processos mostram '[sh] defunct' como comando de processo. Existe uma maneira de descobrir qual processo está se tornando um processo zumbi?

Eu tentei verificar o diretório /proc/PID/ para obter alguma pista sobre o processo zumbi, mas todos os arquivos estão vazios. Como encontrar quem deixou este processo como zumbi ... Existe alguma outra maneira de descobrir isso?

Atualizado / Resolvido: esclareceu a questão e respondeu à minha pergunta como sugerido por andcoz.

    
por user379997 07.03.2012 / 14:03

6 respostas

1

Uma das razões para o processo Zombie é o 'processo pai' não estar esperando pelo 'processo filho' - Executado ps -l que mostra o ID do processo pai, com o qual você pode encontrar exatamente qual processo é responsável por zumbis na máquina .

    
por 08.03.2012 / 11:22
1

Claro que você pode. Há muitas maneiras de fazer isso, o mais comum é provavelmente: 

ps aux

Você pode adicionar um básico | grep -w Z e você terá uma pequena lista de seus zumbis. Se você quer apenas uma lista de processos zumbis e seus pids, você pode fazer como indicado em esta página : 

ps aux | awk '{ print $8 " " $2 }' | grep -w Z

Verifique esta questão para obter mais detalhes sobre as informações do processo.

    
por 07.03.2012 / 14:40
1

A resposta curta é que você não se importa. Um processo de zumbis está morto. Tudo o que consome é um pouquinho de memória do kernel, para essa entrada na tabela de processos.

Como tudo o que resta do processo é a entrada da tabela de processos, você tem pouco para continuar. Um processo de zumbis é um processo morto que o pai não colheu ainda; veja o PPID do processo para ver quem é o pai.

    
por 07.03.2012 / 23:56
1

O subsistema de auditoria do kernel do Linux pode ser muito útil para descobrir quais processos estão se tornando processos zumbis. Acabei de ter a seguinte situação: 

server ~ # ps -ef --forest
[...]
root     16385     1  0 17:04 ?        00:00:00 /usr/sbin/apache2 -k start
root     16388 16385  0 17:04 ?        00:00:00  \_ /usr/bin/perl -T -CSDAL /usr/lib/iserv/apache_user
root     16389 16385  0 17:04 ?        00:00:00  \_ /usr/bin/perl -T -CSDAL /usr/lib/iserv/apache_user
www-data 16415 16385  0 17:04 ?        00:00:00  \_ /usr/sbin/apache2 -k start
www-data 18254 16415  0 17:23 ?        00:00:00  |   \_ [sh] <defunct>
www-data 18347 16415  0 17:23 ?        00:00:00  |   \_ [sh] <defunct>
www-data 22966 16415  0 18:18 ?        00:00:00  |   \_ [sh] <defunct>
www-data 16583 16385  0 17:05 ?        00:00:01  \_ /usr/sbin/apache2 -k start
www-data 18306 16583  0 17:23 ?        00:00:00  |   \_ [sh] <defunct>
www-data 18344 16583  0 17:23 ?        00:00:00  |   \_ [sh] <defunct>
www-data 17561 16385  0 17:12 ?        00:00:00  \_ /usr/sbin/apache2 -k start
www-data 22983 17561  0 18:18 ?        00:00:00  |   \_ [sh] <defunct>
www-data 18318 16385  0 17:23 ?        00:00:00  \_ /usr/sbin/apache2 -k start
www-data 19725 16385  0 17:43 ?        00:00:01  \_ /usr/sbin/apache2 -k start
www-data 22638 16385  0 18:13 ?        00:00:00  \_ /usr/sbin/apache2 -k start
www-data 22659 16385  0 18:14 ?        00:00:00  \_ /usr/sbin/apache2 -k start
www-data 25102 16385  0 18:41 ?        00:00:00  \_ /usr/sbin/apache2 -k start
www-data 25175 16385  0 18:42 ?        00:00:00  \_ /usr/sbin/apache2 -k start
www-data 25272 16385  0 18:44 ?        00:00:00  \_ /usr/sbin/apache2 -k start

A causa desses processos zumbis é provavelmente um script PHP, mas como esses processos filhos do Apache estão processando muitas solicitações HTTP e muitos scripts PHP diferentes, é muito difícil descobrir qual deles poderia ser responsável. O Linux também já desalocou informações importantes desses processos zumbis, de modo que não temos nem mesmo /proc/<pid>/cmdline para descobrir qual script ou -c command /bin/sh pode ter sido executado: 

server ~ # cat /proc/18254/cmdline 
server ~ #

Para descobrir, instalei o auditd : link

Eu configurei as seguintes regras de auditoria: 

auditctl -a always,exit -F arch=b32 -S execve -F path=/bin/dash
auditctl -a always,exit -F arch=b64 -S execve -F path=/bin/dash

Essas regras auditam todas as criações de processo do binário /bin/dash . /bin/sh não funciona aqui, porque é um link simbólico e a auditoria aparentemente só vê o nome do arquivo de destino: 

server ~ # ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Nov  8  2014 /bin/sh -> dash*

Um teste simples agora deve produzir logs de auditoria em /var/log/audit/audit.log (tomei a liberdade e adicionei muitas quebras de linha para melhorar a legibilidade): 

server ~ # sh -c 'echo test'
test

server ~ # tail -f /var/log/audit/audit.log
[...]
type=SYSCALL msg=audit(1488219335.976:43871): arch=40000003 syscall=11 \
  success=yes exit=0 a0=ffdca3ec a1=f7760e58 a2=ffdd399c a3=ffdca068 items=2 \
  ppid=27771 pid=27800 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 \
  fsgid=0 tty=pts7 ses=7532 comm="sh" exe="/bin/dash" key=(null)
type=EXECVE msg=audit(1488219335.976:43871): argc=3 a0="sh" a1="-c" \
  a2=6563686F2074657374
type=CWD msg=audit(1488219335.976:43871):  \
  cwd="/var/lib/iserv/remote-support/iserv-martin.von.wittich"
type=PATH msg=audit(1488219335.976:43871): item=0 name="/bin/sh" inode=10403900 \
  dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1488219335.976:43871): item=1 name=(null) inode=5345368 \
  dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=PROCTITLE msg=audit(1488219335.976:43871): \
  proctitle=7368002D63006563686F2074657374

Muitas das informações são codificadas, mas ausearch pode traduzi-las com -i : 

server ~ # ausearch -i -x /bin/dash | tail                                      
[...]
----
type=PROCTITLE msg=audit(27.02.2017 19:15:35.976:43871) : proctitle=sh 
type=PATH msg=audit(27.02.2017 19:15:35.976:43871) : item=1 name=(null) \
  inode=5345368 dev=08:01 mode=file,755 ouid=root ogid=root rdev=00:00 \
  nametype=NORMAL 
type=PATH msg=audit(27.02.2017 19:15:35.976:43871) : item=0 name=/bin/sh \
  inode=10403900 dev=08:01 mode=file,755 ouid=root ogid=root rdev=00:00 \
  nametype=NORMAL 
type=CWD msg=audit(27.02.2017 19:15:35.976:43871) :  \
  cwd=/var/lib/iserv/remote-support/iserv-martin.von.wittich 
type=EXECVE msg=audit(27.02.2017 19:15:35.976:43871) : argc=3 a0=sh a1=-c \
  a2=echo test 
type=SYSCALL msg=audit(27.02.2017 19:15:35.976:43871) : arch=i386 \
  syscall=execve success=yes exit=0 a0=0xffdca3ec a1=0xf7760e58 a2=0xffdd399c \
  a3=0xffdca068 items=2 ppid=27771 pid=27800 auid=root uid=root gid=root \
  euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts7 \
  ses=7532 comm=sh exe=/bin/dash key=(null) 
----

Se você não quiser restringir a filtragem ausearch a /bin/dash , também poderá usar ausearch -i -m ALL para traduzir o registro completo. Outro bom filtro seria ausearch -i -p <PID of a zombie process> , neste caso ausearch -i -p 27800 .

Apenas deixe essas regras no lugar até que novos processos de zumbis apareçam e, em seguida, procure a criação do processo de um PID zumbi: 

ausearch -i -p <PID>

Isso deve ser muito útil para identificar a causa raiz dos processos zumbis. No meu caso, foi um script PHP que usou proc_open para gerar um script Perl sem fechar o identificador com proc_close .

    
por 27.02.2017 / 19:57
0
ps auxf | grep --color -5 ' Z '

mostra a hierarquia de processos, incluindo zumbis e seus pais Identificar o nome do script zumbi é difícil, pois 'sh defunct' é só você ver

    
por 25.09.2015 / 10:19
0
ps alx | grep defunct

veja o ppid das linhas listadas 

ps alx | grep (ppid of listed lines)
    
por 15.01.2018 / 07:51

Tags

Eu quero atualizar para o Debian Squeeze, mas quais são alguns procedimentos de pré-cuidado que devo tomar? Como entender o resultado retornado pelo comando “nm”