Process impossible a tuer

20.12.2009

Suite à une mauvaise manipulation (synchronistation baie d'un système de fichiers encore monté), les process associés à ce système de fichiers ne peuvent plus être stopper (killer). A part l'arrêt/relance du serveur rien n'y fait. S'il s'agit d'un container Solaris 10, seul l'arrêt relance de la globale permet de rétablir la situation.

Situons nous un peu :

Serveur sous Solaris 10u7 avec des containers
Systèmes de fichiers montés sur la globale zone puis en lofs dans les containers

Soit un container avec une base Oracle où le système de fichiers a été synchronisé (synchro baie) alors qu'il n'était pas démonté au préalable ni dans le container ni dans la globale (normal la base n'a pas été totalement arrêté).

# ps -ef | egrep -i [o]rad3
oracle 18780 1 1 Nov 25 ? 26455:53 oracleORAD3 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

# kill -9 18780

# ps -ef | egrep -i [o]rad3
oracle 18780 1 1 Nov 25 ? 26457:39 oracleORAD3 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

Ca commence mal, non ?

# pfiles 18780
pfiles: no such process: 18780

# pargs 18780
pargs: cannot examine 18780: no such process

# truss -p 18780
truss: no such process: 18780

C'est encore pire. Voyons ce que dtrace peut nous dire (lancer la commande dtrace dans un 1er shell, et le kill dans un 2ème shell)

# dtrace -n 'fbt::sigtoproc:entry /pid == 18780/ { trace(arg2); trace(execname); }'
dtrace: description 'fbt::sigtoproc:entry ' matched 1 probe

# kill -9 18780

Aucun signal reçu pour le pid 18780 et pourtant, le kill est bien initialisé

# signal.d
...
2009 Dec 2 08:12:25 ksh(pid:19084 uid:0) is sending signal 9 to oracle(pid:18780 ppid:1 uid:100)
...

Regardons côté kernel

# ls /proc/18780
as contracts ctl fd lstatus lwp object path psinfo root status watch
auxv cred cwd lpsinfo lusage map pagedata priv rmap sigact usage xmap

# mdb -kw
> 0t18780::pid2proc
30155422488
> 30155422488::kill
mdb: command is not supported by current target

> 30155422488::pfiles
FD TYPE VNODE INFO
0 CHR 0000030023723ec0 /zones/zone01/root/dev/pts/3
1 CHR 0000030023723ec0 /zones/zone01/root/dev/pts/3
2 CHR 0000030023723ec0 /zones/zone01/root/dev/pts/3
3 CHR 000006010b548b00 /zones/zone01/root/dev/null
4 CHR 000006010b548b00 /zones/zone01/root/dev/null
[...]
11 REG 00000300a2ec6940 /zones/zone01/root/oracle/product/10.2.0/rdbms/mesg/oraus.msb
[...]
256 REG 0000030095c4f900 /zones/zone01/root/ORAD3/data/ORAD3_01.ctl
257 REG 00000300a4ba0740 /zones/zone01/root/ORAD3/data/system.256. 662477099
[...]
279 REG 000003009469edc0 /zones/zone01/root/ORAD3/data/o1_mf_risk_dat_4w6ktdfx_.dbf

> ::quit

# cd /proc/18780/fd
ksh: /proc/18780/fd: not found

# gcore 18780
gcore: cannot grab 18780: no such process

Comme on peut le voir, il y a toujours des fd en mémoire. Reste un à faire un arrêt/relance forcé du système. Si quelqu'un à une solution je suis preneur. Et aller pas me dire de ne pas synchroniser les données quand un système de fichiers est monté...