Vous pouvez examiner les structures de contrôle, les tableaux actifs, les images mémoire d'un noyau système actif ou en panne et d'autres informations sur le fonctionnement du noyau à l'aide de l'utilitaire mdb.
Ainsi,
# cd /var/crash
Si vous n'êtes pas sûr de l'emplacement du vidage sur incident, exécutez la commande dumpadm pour déterminer l'emplacement de stockage des fichiers de vidage sur incident du noyau configuré sur le système. Ainsi,
# /usr/sbin/dumpadm Dump content: kernel pages Dump device: /dev/zvol/dsk/rpool/dump (dedicated) Savecore directory: /var/crash Savecore enabled: yes Save compressed: on
# /usr/bin/mdb [-k] crashdump-file
Indique le mode de débogage du noyau en supposant que le fichier est un fichier de vidage sur incident du système d'exploitation.
Indique le fichier de vidage sur incident du système d'exploitation.
Ainsi,
# /usr/bin/mdb -K vmcore.0
La commande peut également être définie comme suit :
# /usr/bin/mdb -k 0
> ::status . . . > ::system . . .
Si vous souhaitez utiliser la commande ::system dcmd pour examiner le vidage sur incident, le dump noyau doit être un vidage sur incident de noyau et l'option –k doit avoir été spécifiée lors du démarrage de l'utilitaire mdb.
> $quit
Cet exemple montre des sorties possibles de l'utilitaire mdb avec des informations système et l'identification des paramètres réglables définis dans le fichier système /etc/system.
# cd /var/crash # /usr/bin/mdb -k unix.0 Loading modules: [ unix krtld genunix ip nfs ipc ptm ] > ::status debugging crash dump /dev/mem (64-bit) from ozlo operating system: 5.10 Generic sun4v > ::system set ufs_ninode=0x9c40 [0t40000] set ncsize=0x4e20 [0t20000] set pt_cnt=0x400 [0t1024] > $q