Иногда так случается, что ядро системы не может корректно обработать внутреннюю ошибку. В этом случае происходит паника (kernel panic), приводящая к полной остановке системы, синхронизации ФС и перезагрузке. Все было бы очень грустно, если бы мы не могли выяснить причину паники, а имея лишь состояние регистров и стек вызовов ядра сделать это практически невозможно. К счастью, в Solaris предусмотрен механизм dumpа ядра, и наличествуют специальные утилиты для его анализа - Solaris Crash Analisys Tool (Solaris CAT).
В первую очередь следует убедиться что у вас корректно настроено dump-устройство, и его размер достаточно большой, чтобы сохранить всю память ядра (за исключением ZFS ARC и кэша ФС, конечно же). Оно обычно является или разделом, или мета-устройством SVM, или zvol и обычно совпадает с устройством swap:
root@blade # dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c0t0d0s1 (swap)
Savecore directory: /var/crash/blade
Savecore enabled: yes
Если вы используете SVM, то следует dump-устройство на meta-устройство SVM:
root@blade # dumpadm -d swap
Скачиваем и устанавливаем пакет SUNWscat. Надо заметить, что требуется scat той же архитектуры, что и коре-файл. scat можно скачать здесь: Sun Downloads Center - Solaris (я использовал версию 5.2)
root@blade # gunzip SUNWscat5.2-GA-sparc.pkg.gz
root@blade # pkgadd -d SUNWscat5.2-GA-sparc.pkg SUNWscat
и следуйте инструкциям.
После этого scat будет установлен в директорию /opt/SUNWscat
Самый простой способ вызвать панику системы - использовать команду sync из OBP, или деструктивную функцию panic из DTrace.
Вызовем scat для новой коры (0 - ее номер).
root@blade # cd /var/crash/blade/
root@blade # /opt/SUNWscat/bin/scat 0
scat - еще и цветной
Какую информацию мы можем вытащить из коры? Теоретически - практически любую - если немного знать ассемблер и структуры ядра, то тут помогут функция rdi (для дизассемблера) и sdump (для вывода структур ядра).
Вообще, scat имеет подробную внутреннюю справку - help выведет список всех комманд, разделенных по категориям, а help <команда выдаст синтаксис каждой из них и подробное описание).
Например так можно получить информацию о vnode файла:
SolarisCAT(vmcore.0/10U)> proc | grep bash
0x30002556058 3295 3259 0 4726784 2318336 548864 12 bash
0x30002566040 2939 2923 0 4726784 2228224 548864 19 bash
SolarisCAT(vmcore.0/10U)> findfiles 3295
Process 3295: bash
511 file slots allocated.
file 0: vnode @ 0x3000406f5c0 /devices/pseudo/pts@0:2
<cut>
Теперь, введя команду.
SolarisCAT(vmcore.0/10U)> sdump 0x30001294c00 vnode
мы получим всю информацию по открытому в bash псевдо-терминалу.
Итак, небольшой ликбез по командам:
-
stat - общая информация по коре
-
analyze и panic - выдают общую информацию о панике
-
sdump - выводит структуру в соответствующем формате. Вообще, формат структур описан в CTF-секциях модулей ядра, о чем писал Сергей Клименков: Создание заголовков CTF для загружаемых модулей ядра
-
mdump - выводит область памяти в шестнадцатеричном формате.
-
stack - выводит стек вызовов и состояние регистров (в случае если указана опция -L)
-
findfiles - список открытых файлов процессом.
-
thread и tlist - выводят информацию по потокам (LWP)
-
rdi - дизассемблирует код
-
symbols - выводит список символов ядра.
Некоторые команды повторяют имена файлов и команд, имеющихся в системе, например ndd позволяет посмотреть параметры сетевых драйверов, а etcsystem - системные параметры в одноименном файле.
Надо заметить, что scat умеет перенаправлять вывод своей команды на grep, или скажем less, что несколько упрощает процесс анализа коры, например:
SolarisCAT(vmcore.0/10U)> symbols | grep isns
iscsi:iscsid_do_isns_query_one_server 0x7ba3a724 0x10c 0x10c 2 1
iscsi:iscsid_do_isns_query 0x7ba3a830 0xa4 0xa4 2 1
iscsi:isns_scn_callback 0x7ba3a9e0 0x284 0x284 2 1
iscsi:iscsid_thread_isns 0x7ba3b6e8 0x104 0x104 2 0
<cut>
Использование scat необходимо когда критически важная система дает программный сбой и необходимо быстро выявить и устранить ошибку. В совокупности с DTrace и mdb - это очень удобное и функциональное средство наблюдения за системой.