Quando um processo se torna zumbi, muitas vezes o nome do processo não aparece com o comando ps, e no lugar fica com o nome <defunct>. Nessas horas o AIX Kernel Debugger (comando kdb) é muito útil, pois identificamos qual aplicativo/processos se tornou zumbi.

Uma observação importante: o kdb mostra informações que estão em memória RAM, não identificando os que estão em swap. Abaixo um procedimento básico do kdb, executado como root com o prompt:

# kdb
(0)>

Listar todos os processos defuntos/zumbis:

(0)> p * | grep -i zombie

Mostrar apenas um processo defunto utilizando o grep e o PID do processo em hexadecimal:

(0)> p * | grep <hex pid>

Mostrar informações sobre o processo:

(0)> p <process slot>

Listar todas as threads do processo. Cada thread tem um slot number e um nome:

(0)> tpid <hex pid>

Mostrar as informações sobre uma única thread usando o thread slot number:

(0)> th <thread slot>

Mostrar as informações do processo, incluindo espaço do usuário e nome do processo (exec file):

(0)> u <thread slot> | grep "exec file"

Exemplo prático:

ps -ef |grep -i def
root  721136  282742   0                  0:00 <defunct>

# kdb
(0)> p * | grep -i zombie
pvproc+02C000  176 <zombie> ZOMB   00B00F0 0045076 00007FFFFFFFF080   0 0001
(0)>

(0)> p 176
     SLOT NAME     STATE      PID    PPID          ADSPACE  CL #THS

pvproc+02C000 176 <zombie> ZOMB 00B00F0 0045076 00007FFFFFFFF080 0 0001

NAME....... <zombie>
STATE...... stat  :05  .... xstat :FF00
FLAGS...... flag  :00210001 LOAD EXIT EXECED
[....]

(0)> tpid 00B00F0
     SLOT NAME     STATE    TID PRI   RQ CPUID  CL  WCHAN

pvthread+022200  546 <zombie> ZOMB  2220E7 03C    0         0
pvthread+033600  812 <zombie> ZOMB  3360ED 03C    2         0
pvthread+02D800  528 <zombie> ZOMB  2D8027 03C    0         0
pvthread+033500  822 <zombie> ZOMB  335089 03C    0         0

(0)> th 546
       SLOT NAME     STATE    TID PRI   RQ CPUID  CL  WCHAN

pvthread+022200  546 <zombie> ZOMB  2220E7 03C    0         0  

NAME................ <zombie>
WTYPE............... WZOMB    
.................tid :00000000002220E7  ......tsleep :FFFFFFFFFFFFFFFF
...............flags :00000000  ..............flags2 :00000000
...........pmcontext :00000000
DATA.........pvprocp :F100070F0002C000 <pvproc+02C000>
LINKS.....prevthread :F100070F10022200 <pvthread+022200>
..........nextthread :F100070F10022200 <pvthread+022200>
DISPATCH.......synch :FFFFFFFFFFFFFFFF
SCHEDULER...affinity :00000000  .................pri :0000003C
.............boosted :00000000  ...............wchan :0000000000000000
...............state :00000006  ...............wtype :0000000C
MISC       ..tv_eyec :7076746850524F43 (pvthPROC)
CHECKPOINT......vtid :00000000  .............chkfile :0000000000000000
LOCK........ lock_d @ F100070F10022230 0000000000000000
PROCFS......procfsvn :0000000000000000
NUMA............rset :0000000000000000
PROFILING.....prbase :0000000000000000  ....prpinned :0000000000000000
[....]

(0)> u 546 | grep "exec file"
Current exec file information:
   exec file..oracle
(0)>

No nosso exemplo o processo defunto é o Oracle. Identificando qual aplicativo está se tornando <defunct> agiliza o processo de troubleshooting.

André Facina