Overblog Suivre ce blog
Administration Créer mon blog
16 août 2010 1 16 /08 /août /2010 21:04

 

 

I'm really surprised when I still see Solaris servers configured without the possibility of taking a dump. These next few lines explain how to do that especially for Solaris x86 (use interrupt NMI).

 

 

To achieve this, it's necessary to configure several elements in the Solaris system:

  • Activation system in debug mode
  • Correct setting for taking dump
  • System configuration for NMI interrupts

 

How to start in debug mode Solaris 10x86 ? It's really simple, just add parameter "kadb" at the end of line "multiboot" in the file "menu.lst" then reboot.

 

As you can see below:

 

# pwd
/rpool/boot/grub

# cat menu.lst
[...]
title s10x_u9wos_14a
bootfs rpool/ROOT/s10x_u9wos_14a
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B console=ttyb,$ZFS-BOOTFS kadb
module /platform/i86pc/boot_archive

[...] 

 

How to configure correct setting for taking dump ? Just use the command "dumpadm". Two things to check: the dump device and the savecore directory exist with the correct size (the size depends on RAM - two different policies on this subjetc: the size of dump device is the same as the RAM or not).

 

For exemple:

 

# dumpadm
      Dump content: kernel pages
       Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash/zlap
  Savecore enabled: no
   Save compressed: on

# prtconf | grep -i memory
Memory size: 16384 Megabytes

# zfs get volsize rpool/dump
NAME           PROPERTY  VALUE    SOURCE
rpool/dump  volsize       512M     -

# df -h /var/crash/zlap
Filesystem            Size  Used Avail Use% Mounted on
rpool/ROOT/solaris     54G  9.9G   16G  39% / 

 

How to configure system for NMI interrupt ? Just add the following lines in the file /etc/system then reboot.

 

For exemple: 

 

# egrep apic /etc/system
set pcplusmp:apic_kmdb_on_nmi=1
set pcplusmp:apic_panic_on_nmi=1

 

Now, if the system hang, you can send an interrupt NMI and thus take a dump. Either you use the "ipmi" command (if ipmi command are available on ILOM's server) or you use the website of the ILOM's server to generate an interrupt NMI.

 

For exemple (ipmi command):

 

# ipmitool -I lanplus -H server-rsc -U root chassis power diag

 

 

A simple demonstration...

 

On server :

 

$ ssh zlap

 

# uname -a

SunOS zlap 5.10 Generic_142910-17 i86pc i386 i86pc

# prtdiag

System Configuration: HP ProLiant DL360 G5

BIOS Configuration: HP P58 05/18/2009

BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)

[...]

 

 

On Rilo server  :

 

$ ssh admin@zlap-rsc

root@zlap-rsc's password:
User:root logged-in to ILOLD75MU6996.(XXX.XXX.XXX.XX)
iLO 2 Advanced 2.05 at 15:38:15 Dec 17 2009
Server Name: DL360G5P-34-13
Server Power: On

</>hpiLO->
</>hpiLO-> nmi server

</>hpiLO-> vsp

 

Starting virtual serial port.
Press 'ESC (' to return to the CLI Session.

</>hpiLO-> Virtual Serial Port active: IO=0x02F8 INT=3

[1]> 
[1]> ::showrev
Hostname: zlap
Release: 5.10
Kernel architecture: i86pc
Application architecture: amd64
Kernel version: SunOS 5.10 i86pc Generic_142910-17
Platform: i86pc

[1]> $<systemdump
nopanicdebug:   0               =       0x1

panic[cpu1]/thread=fffffe80005e0c60: BAD TRAP: type=e (#pf Page fault) rp=fffffe80005e0980 addr=0 occurred in module "<unknown>" due to a NULL pointer dereference

sched: #pf Page fault
Bad kernel fault at addr=0x0
pid=0, pc=0x0, sp=0xfffffe80005e0a78, eflags=0x10002
cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6f0<xmme,fxsr,pge,mce,pae,pse>
cr2: 0 cr3: 14717000 cr8: c
        rdi: fffffffffbc7eab0 rsi:              2f8 rdx:              2f8
        rcx:                a  r8:                0  r9: ffffffffa4f71c90
        rax: fffffffffbcecbe0 rbx: ffffffffef8f1250 rbp: fffffe80005e0a80
        r10: fffffe80005e09c0 r11:                0 r12: fffffe80005e0af0
        r13:                1 r14: fffffffffbc561c0 r15:                1
        fsb:                0 gsb: ffffffffa44fb800  ds:               43
         es:               43  fs:                0  gs:              1c3
        trp:                e err:                0 rip:                0
         cs:               28 rfl:            10002 rsp: fffffe80005e0a78
         ss:               30

fffffe80005e0890 unix:die+da ()
fffffe80005e0970 unix:trap+5e6 ()
fffffe80005e0980 unix:cmntrap+140 ()
fffffe80005e0a80 0 ()
fffffe80005e0a90 genunix:kdi_dvec_enter+d ()
fffffe80005e0ab0 unix:debug_enter+66 ()
fffffe80005e0ac0 pcplusmp:apic_nmi_intr+94 ()
fffffe80005e0ae0 unix:av_dispatch_nmivect+1f ()
fffffe80005e0af0 unix:nmiint+17e ()
fffffe80005e0be0 unix:i86_mwait+d ()
fffffe80005e0c20 unix:cpu_idle_mwait+125 ()
fffffe80005e0c40 unix:idle+89 ()
fffffe80005e0c50 unix:thread_start+8 ()

syncing file systems... done
dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
 0:01 100% done
100% done: 320938 pages dumped, dump succeeded
rebooting...

 

 

It's very simply... no ?

 

 

For you computer culture, here are some links on the topic:

 

 

 

 

 

Published by gloumps - dans kernel
commenter cet article
2 août 2010 1 02 /08 /août /2010 16:08

 

Very good article on changing a root password when it's lost. Caution still the policy of passwords must be begin with 'passwd' in the nsswitch.conf file. Click...

Published by gloumps - dans divers
commenter cet article
1 juillet 2010 4 01 /07 /juillet /2010 11:28

 

Le 18 juin dernier, j'ai eu l'occasion de présenter un retour d'expérience sur la mise en place d'une solution de virtualisation (sous Solaris 10 avec container) lors du salon annuel de l'itiforums (en partenariat avec le CRIP).

 

Petit résumé des faits :

 

Différents constats monétaires ou non sont à l'origine de ce projet portant à restructurer l'infrastructure de test/dev/uat. La mise en place d'une solution de virtualisation basée sur les zones Solaris à permis de répondre aux différents besoins buisness exprimés lors de cette étude tout en améliorant les gains de productivités.. Les slides sont disponibles si vous suivez le lien.

 

Vous trouverez un très bon résumé de la la présentation (un peu plus technique) sur le blog d'Eric Bezille à l'adresse suivante : lien. J'ai présenté ce sujet lors d'une conférence Guses en décembre dernier. Si vous souhaiter obtenir cette présentation merci de me contacter.

Published by gloumps - dans divers
commenter cet article
29 juin 2010 2 29 /06 /juin /2010 15:05

 

Afin de mieux appréhender la gestion des ressources CPU, il est nécessaire de mieux cerner le système et notamment l'ordonnancement des processus. A ce titre j'ai eu l'occasion de faire une petite présentation pour l'association Guses sur l'ordonnencement dans Solaris/Opensolaris  en m'appuyant sur des cas pratiques où l'optimisation des ressources CPU est nécessaire. La présentation est disponible ici.

Published by gloumps - dans kernel
commenter cet article
21 avril 2010 3 21 /04 /avril /2010 23:07

 

Lors de la création d'un snapshot, j'obtiens un message d'erreur EBUSY. Il s'agit d'un bug connu mais j'ai décidé de l'analyser. En voiture...

 

# zfs snapshot zone01/root@today
cannot create snapshot 'zone01/root@today': dataset is busy

 

Il s'agit d'un bug déjà connu mais j'ai eu envie de l'analyser un peu. Je commence par tracer le process :

 

# truss  zfs snapshot zone01/root@today
...
ioctl(3, ZFS_IOC_OBJEST_STATS, 0xFFBFCB90)
 = 0
ioctl(3, ZFS_IOC_SNAPSHOT, 0xFFBFE478)
 Err#16 EBUSY
...

 

L'ioctl passe la main au driver ZFS. On sait juste que le code retour de correspond à EBUSY (16). Je vais donc rechercher avec dtrace les fonctions ZFS lors de la création du snapshot.

 

# ./zfs.d
FCT Code Retour
... 
3
 <- dmu_objest_snapshot_one  16
3    <-
 dmu_objest_snapshot 16
3  <-
 zfsdev_ioctl 16

 

Ce petit script dtrace (script maison) permet de localiser facilement les fonctions ZFS appelées lors de l'exécution de la commande. On remarque les choses suivantes :

  • zfsdev_ioctl() transmet le code retour égal 16 à ioctl().
  • dmu_objest_snaphot() transmet le code retour égal 16 à zfsdev_ioctl()
  • dmu_objest_snaphot_one() transmet le code retour égale 16 à dmu_objest_snaphot()

 

Après lecture du code source de ZFS, je remarque que la fonction dmu_objest_snaphot_one() récupère le code d'erreur de zil_suspend(). Ci-joint l'extrait de la fonction :

 

int zil_suspend(zilog_t *zilog)
{
...
mutex_enter(&zilog->zl_lock);

if (zh->zh_claim_txg != 0) {
mutex_exit(&zilog->zl_lock);
return (EBUSY);

 

Lors de la création du snapshot, la zil doit être vide. Vérifions maintenant si je suis bien dans ce cas :

 

# zdb -ivv snapshot zone01/root
Dataset zone01/root@today [ZPL], ID 21, cr_txg 14, 370 Mo, 9556 objects

ZIL header : claim_txg 98167, seq 0

 

Il semble en effet que je sois dans ce cas. J'applique le workround afin de vérifier complètement ces hypothèses :

 

# zfs list zone01/root
NAME USED AVAIL REFER MOUNTPOINT
zone01/root@today 370 Mo 24.5 Go 370 Mo legacy

# mount | egrep -c zone01/root
0
# zfs set mountpoint=/test zone01/root
# zfs umount zone01/root
# zfs mount zone01/root
# zdb -ivv snapshot zone01/root

Dataset zone01/root@today [ZPL], ID 21, cr_txg 14, 370 Mo, 9556 objects

ZIL header : claim_txg 0, seq 0

 

Comme on peut le voir la zil est vide. J'essaye de créer mon snapshot :

 

# zfs snapshot zone01/root@today
# zfs list -t snapshot | egrep zone01/root@today
zone01/root@today
 0 - 370 Mo -

 

J'ai pu créer mon snapshot ce qui prouve que mon analyse semble correct. J'ai réussi à démontrer le bug 6462803 corrigé dans le patch kernel 141444-01 (à l'heure actuelle, la version de ce patch n'est plus dispo voir la version 141444-09).

 

Published by gloumps - dans zfs
commenter cet article
16 avril 2010 5 16 /04 /avril /2010 19:15

 

Voyons ce que nous apporter le protocole CDP (Cisco Discovery Protocol) quand on capture l'un de ces paquets depuis un serveur. Suivre le lapin blanc...

 

Les équipements CISCO utilisent un protocole de découverte réseau nommé CDP. Je ne fais pas rentrer dans l'explication de ce protocole mais c'est grâce à lui que nous pouvons récupérer les informations suivantes :

 

# snoop -d bnx0 -o /tmp/snoop -s 400 -c 1 ether dst 1:0:c:cc:cc:cc and ether[20:2]=0x2000
Using device /dev/bnx0 (promiscuous mode)
1 1 packets captured

# strings /tmp/snoop
snoop
KEj
**a:
"myswitch.domain.com
Cisco IOS Software, s72033_rp Software (s72033_rp-IPSERVICESK9-M), Version 12.2(33)SXH2, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Sat 29-Mar-08 13:28 by prod_rel_team
cisco WS-C6509-E
GigabitEthernet4/27

 

Cela permet notamment d'obtenir le nom du switch et le port sur lequel le serveur est connecté. Cela fonctionne aussi avec la commande tcpdump (ajouter simplement l'option verbose).

Published by gloumps - dans réseau
commenter cet article
20 décembre 2009 7 20 /12 /décembre /2009 11:35

 

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

Published by gloumps - dans kernel
commenter cet article
18 décembre 2009 5 18 /12 /décembre /2009 14:49

 

Mardi 15 décembre, j'ai exposé un retour d'expérience sur la virtualisation Solaris dans le cadre de ma mission. Un petit résumé est disponible ici (merci à Eric pour la synthèse). Si vous voulez un peu plus d'info, contacter moi.

Published by gloumps - dans administration
commenter cet article
5 décembre 2009 6 05 /12 /décembre /2009 22:33

 

Voilà qu'un beau matin, une node d'un cluster Oracle RAC décide de se tuer. Voiçi l'analyse postmortem qui a permis de détecter un problème de désynchronisation d'horloge (TOD & tick). On commence par ici ...

 

# cd /var/core/`hostname`
# file *.0
unix.0:         ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC1 Extensions Required, statically linked, not stripped, no debugging information available 

vmcore.0:       SunOS 5.10 Generic_127127-11 64-bit SPARC crash dump from 'xxxxxx'

# mdb unix.0 vmcore.0
Loading modules: [ unix krtld genunix specfs dtrace ufs sd mpt px ssd fcp fctl md ip hook neti sctp arp usba zfs random ipc nfs sppp crypto cpc fcip logindmux ptm ] 

> ::panicinfo 
             cpu               17 
          thread      30009bf86c0 
         message forced crash dump initiated at user request 
          tstate       4400001600 
              g1                b 
              g2                0 
              g3          11ca714 
              g4              6e0 
              g5         88000000 
              g6                0 
              g7      30009bf86c0 
              o0          1211a68 
              o1      2a100a9b9e8 
              o2                1 
              o3                0 
              o4 fffffffffffffff5 
              o5             1000 
              o6      2a100a9b0b1 
              o7          1068368 
              pc          104980c 
             npc          1049810 
               y                0 

 > 30009bf86c0::thread -p 
            ADDR             PROC              LWP             CRED 
0000030009bf86c0      600b7cb50b8      600bab9af30      6009a003d98 

 > 600b7cb50b8::ps -ft 
S    PID   PPID   PGID    SID    UID      FLAGS             ADDR NAME 
R  29139  28993   1772   1772      0 0x4a004000 00000600b7cb50b8 /crs/10.2.0/bin/oprocd.bin run -t 1000 -m 500 -f 
        T     0x30009bf86c0 <TS_ONPROC> 

> 600b7cb50b8::walk thread |::findstack 
stack pointer for thread 30009bf86c0: 2a100a9b0b1 
  000002a100a9b161 kadmin+0x4a4() 
  000002a100a9b221 uadmin+0x11c() 
  000002a100a9b2e1 syscall_trap+0xac()

 

Le démon opcrod est à l'origine du suicide de la node (commande uadmin). Pour rappel le démon oprocd surveille le cluster RAC et réalise le fencing du cluster RAC (isolement primitif d'un noeud lors d'une défaillance de celui-ci). Lors de ce fencing, oprocd effectue des vérifications de fonctionnement, puis se fige. Si le réveil de l’oprocd n’a pas lieu avant une durée configurée, celui-ci procède au redémarrage du noeud du cluster.

 

Après une petite recherche, il s'agit d'un problème de TOD : bug suivant 6595936. L'ajout des deux paramètres suivants dans le fichier system a permis de corriger le problème définitivement.

 

# cat /etc/system
...
* Bug ID 6595936
set tod_broken = 1
set dosynctodr = 0
..


Published by gloumps - dans kernel
commenter cet article
1 décembre 2009 2 01 /12 /décembre /2009 23:04

 

Amélioration du script Dtrace sig.d, pour permettre d'afficher un plus grand nombre d'informations. Ca ressemble à cela :

 

#!/usr/sbin/dtrace -qs

proc:::signal-send
{
printf("%Y %s(pid:%d uid:%d) is sending signal %d to %s\
(pid:%d ppid:%d uid:%d)\n", walltimestamp,execname,\
pid,uid,args[2],args[1]->pr_fname,args[1]->pr_pid,\
args[1]->pr_ppid,args[1]->pr_uid);
}

 

Pas très compliqué à faire... Ce petit script Dtrace m'a permis de prouver que l'arrêt brutale d'une application ne provenait pas du système mais de l'application elle-même.

Published by gloumps - dans dtrace
commenter cet article