Применение аварийного дампа


Если вы разработчик ядра, то в этом месте перестанете меня слушать, полагаясь на свой опыт отладки. Однако если вы системный администратор, то, вероятно, недостаточно хорошо владеете языком C и не знакомы с внутренним устройством ядра, чтобы надеяться на его успешную отладку в сложных случаях. Поэтому сосредоточим внимание на извлечении информации, помогающей разработчику идентифицировать проблему.

После создания дампа можно найти файлы vmcore.0 и info.0 в каталоге /var/crash. (Каждый последующий дамп получает следующий по порядку номер.) Файл info.0 содержит базовую информацию о дампе, например раздел, откуда был извлечен дамп, дату создания и успешно ли он был создан. Файл vmcore.0 — это образ памяти ядра в момент аварии. Это полный отчет, о чем думало ядро в момент возникновения паники.

Если аварийные ситуации будут повторяться часто, то аварийные дампы могут переполнить раздел /var. При многократном повторении аварийной ситуации определенного типа вам нужен только один дамп этого типа. Дампы прежних версий FreeBSD бесполезны и могут быть удалены.

Получение обратной трассировки

Зайдите в каталог, где находится запаниковавшее ядро. Это может быть ваше рабочее ядро или, возможно, тестовое ядро. В каталоге ядра должны присутствовать два файла для каждого модуля, один файл с именем модуля, а другой с расширением .symbols. Файлы с расширением .symbols — это отладочные образы. Перейдя в каталог с ядром, запустите команду kgdb(1), передав ей имя файла kernel.symbols и полный путь к файлу с дампом памяти vmcore:

# cd /boot/kernel.panicked/
# kgdb kernel.symbols /var/crash/vmcore.0

kgdb(1) выведет краткую информацию об авторских правах на отладчик gdb(1) и о лицензии (kgdb(1) — это, действительно, модифицированный отладчик gdb(1), специально настроенный для отладки ядра). Затем вы увидите копию сообщения о панике и в конце получите от kgdb(1) приглашение к вводу. Здесь вы, наконец, сможете получить требуемую обратную трассировку.

Это полная запись всего, что делало ядро, в обратном порядке. Строка с номером 0 показывает, что отладчик вызвал функцию doadump, которая выполняет запись дампа на диск. Вслед за этой строкой мы видим различные вызовы отладчика. Строка 8 содержит само сообщение о панике, а слово panic отмечает момент, когда сервер начал падать.

В случае паники ядро вызывает функцию panic и иногда функцию trap. Вам могут встретиться варианты этих двух слов, например db_trap, kdb_trap, calltrap и т. д., однако нас интересуют только простые вызовы trap или panic, без всяких украшений. Поищите эти функции в выводе kgdb(1). В предыдущем примере вызов функции panic присутствует в строке 8. Строки 3, 4, и 5 содержат функции, которые отладчик вызывает для точного выяснения произошедшего и выбора последующих действий.

Строка 9 показывает, что произошло непосредственно перед тем, как система решила удариться в панику в строке 8. В строке 9 мы видим:

#9 0xc07400b7 in _mtx_lock_sleep (п=0хс228са30, tid=3255925760, opts=0,
   file=0xc0a51887 "/usr/src/sys/dev/aic7xxx/aic7xxx_osm.h", line=203)
   at /usr/src/sys/kern/kern_mutex.с:311

Шестнадцатеричные числа говорят не так уж много, но очень похоже на сообщение о панике. Система FreeBSD запуталась при выполнении кода, начинающегося со строки 203 файла /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h. Эта информация подсказывает разработчику, где искать причины неполадок. Однако мы можем заглянуть немного глубже. Используйте команду up и номер строки, которая вас заинтересовала:

(kgdb) up 9
#9 0xc07400b7 in _mtx_lock_sleep (m=0хс228са30, tid=3255925760, opts=0,
   file=0xc0a51887 "/usr/src/sys/dev/aic7xxx/aic7xxx_osm.h", line=203)
   at /usr/src/sys/kern/kern_mutex.с:311
311             KASSERT((m->lock_object.lo_flags & LO_RECURSABLE) != 0,

Здесь мы видим фактическую строку кода, который вызвал панику в системе. На данном этапе я должен отдать ядро на милость разработчиков. Включив эту информацию в отчет о проблеме, вы уменьшите объем переписки, однако вполне возможно, что разработчик просто скажет: «Ой!» — и отправит вам исправления без объяснения причин неполадки. Чтобы покинуть отладчик kgdb(1), введите команду quit:

(kgdb) quit

Если вы собираетесь перестраивать ядро, сохраните запаниковавшее ядро для дальнейших исследований. Вы можете исследовать дамп ядра только с ядром, которое запаниковало.

Все вышеупомянутое — довольно хорошее начало для создания отчета о проблеме. Вы можете точно видеть, где система остановилась и на какой строке кода это произошло. Заинтересовавшиеся разработчики наверняка ответят вам и сообщат, какие еще команды следовало бы ввести в командной строке kgdb, но как бы то ни было, вы находитесь на правильном пути решения проблемы и оказания помощи ребятам из FreeBSD.

vmcore и безопасность

В файле vmcore присутствует все содержимое памяти ядра на момент возникновения паники. Сюда может входить различная секретная информация. Злоумышленник может воспользоваться этими данными, чтобы проникнуть в вашу систему. В своем письме разработчик FreeBSD может попросить у вас копию файла vmcore и само ядро. Для этого у него могут быть вполне разумные причины: отладка пройдет легче, а количество писем с уточняющими вопросами значительно сократится. Тем не менее внимательно продумайте возможные последствия предоставления такой информации. Если вы не знаете специалиста, который попросил вас об этом, или не доверяете ему, то не следует посылать этот файл!

Однако если паника воспроизводима, можно произвести «холодную» перезагрузку системы, войти в однопользовательский режим и немедленно инициировать панику. Если в системе не была запущена ни одна программа, содержащая конфиденциальную информацию, и никто не набирал пароли в системе, то в дампе не окажется опасной информации. Таким образом, воспроизведение паники в однопользовательском режиме позволит сгенерировать «чистый», свободный от секретной информации файл дампа памяти. Загрузите систему в однопользовательском режиме и введите команды:

# mount -ar
# /etc/rc.d/dumpon start
#
команда_которая_вызвала_панику

Первая команда монтирует файловые системы «только для чтения», поэтому после паники не понадобится запускать fsck(8). Вторая команда указывает системе, куда поместить дамп. Последней следует команда, вызвавшая панику в системе. Чтобы вызвать панику, может потребоваться не одна команда, но в большинстве случаев мы получим чистый дамп. Если для воспроизведения паники требуется загрузить конфиденциальную информацию, то эта информация будет присутствовать в дампе.

Комментарии запрещены.