Solaris mon amour

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é...