AIX - Identificando processos zumbis

Colaboração: André Luiz Facina

Data de Publicação: 13 de julho de 2010

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 através dele identificamos qual aplicativo/processos se tornou zumbi.

Uma observação importante é que, o kdb mostra informações que estão em memória RAM, dessa forma processos que estão em swap o kdb não consegue identificar.

Abaixo um procedimento básico do kdb:

Executar o comando kdb como root

  # kdb

Irá aparecer o prompt do 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 informções do processo, isso inclui as informações do espaço do usuário, onde inclui o nome do processo (exec file)

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

Exemplo prático:

  aix@andre$ 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 atualmente trabalha na IBM como especialista em Unix e Storage.