De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.
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.