При работе ядра, находящегося в разработке (например: FreeBSD-CURRENT), при критичных условиях (к примеру: очень высокая средняя нагрузка, десятки тысяч соединений, исключительно большое количество одновременно работающих пользователей, сотни процессов jail(8) и так далее) или при использовании новой возможности в драйвере устройства в FreeBSD-STABLE (пример: PAE) оно иногда будет завершать свою работу аварийно. В случае, если это произошло, в этой главе показано, как извлекать полезную информацию из произошедшего сбоя.
При аварийном завершении работы ядра перезагрузка системы неизбежна. После перезагрузки системы содержимое физической памяти системы (RAM) теряется, так же как и всё содержимое раздела подкачки перед сбоем. Для сохранения состояния физической памяти ядро использует устройство подкачки в качестве места временного хранения содержимого оперативной памяти после перезагрузки, следующей за аварийным завершением работы. С этой целью при загрузке FreeBSD после аварийного останова образ ядра может быть извлечён и применяться для отладки.
Замечание: Устройство подкачки, которое было отконфигурировано в качестве устройства для дампа продолжает выступать в роли устройства подкачки. В настоящее время выполнение дампов на устройства, не предназначенные для организации подкачки (например, ленты или CDRW), не поддерживается. Понятие ''устройство подкачки'' является синонимом ''раздела подкачки.''
Чтобы суметь извлечь образ, который можно использовать, требуется, чтобы по крайней мере один раздел подкачки был достаточно большим, чтобы разместить на нём весь объём физической памяти. Когда ядро аварийно завершает работу, перед перезагрузкой системы, ядро достаточно умно, чтобы проверить, было ли отконфигурировано устройство подкачки в качестве устройства для хранения дампов. Если оно является устройством, подходящим для сброса дампа, то ядро сбрасывает содержимое физической памяти на устройство подкачки.
До того, как ядро начнёт сбрасывать содержимое физической памяти на устройство
хранения дампов, последнее должно быть отконфигурировано. Устройство хранения дампов
задаётся при помощи команды dumpon(8), указывающей
ядру, куда сохранять аварийные дампы ядра. Программа dumpon(8) должна быть
вызвана после конфигурации раздела подкачки по команде swapon(8). Обычно это
осуществляется установкой переменной dumpdev в файле rc.conf(5) в значение,
соответствующее пути к устройству подкачки (рекомендованный способ извлечения дампа
ядра).
Либо устройство для сброса образа памяти может быть задано явно в параметре dump строки config(5) конфигурационного файла вашего ядра. Такой способ использовать не рекомендуется и он должен использоваться, только если ядро аварийно завершает свою работу до того, как можно было бы запустить dumpon(8).
Подсказка: Проверьте содержимое файла /etc/fstab или выдачу swapinfo(8) на предмет наличия устройств подкачки.
Важно: Удостоверьтесь, что каталог
dumpdir, указанный в rc.conf(5), существует до аварийного останова ядра!# mkdir /var/crash # chmod 700 /var/crashЗапомните также, что содержимое /var/crash является важной информацией, весьма вероятно, содержащей конфиденциальную информацию, в частности, пароли.
После того, как аварийный образ был записан на соответствующее устройство, его нужно
извлечь до момента монтирования устройства подкачки. Для извлечения дампа из устройства
его сохранения, воспользуйтесь утилитой savecore(8). Если в
файле rc.conf(5) было задано
устройство dumpdev, то savecore(8) будет
запущена автоматически при первой после аварийного останова загрузке в
многопользовательском режиме и до монтирования устройства подкачки. Местоположение
извлечённого образа памяти определяется значением переменной dumpdir из файла rc.conf(5), которое по
умолчанию указывает на каталог /var/crash, а файл будет
называться vmcore.0.
В случае, если в каталоге /var/crash (или в том, на который
указывает dumpdir) уже существует файл с именем vmcore.0, то ядро будет увеличивать порядковый номер для каждого
аварийного останова, чтобы избежать перезаписи существующих файлов vmcore (к примеру, vmcore.1). В процессе
отладки скорее всего, в качестве нужного vmcore вы будете
использовать версию vmcore с наибольшим номером в /var/crash.
Подсказка: Если вы тестируете новое ядро, но вам нужно загрузить и работать с другим ядром, чтобы получить нормально функционирующую систему, то загрузите его в однопользовательском режиме при помощи флага
-s, указываемого при загрузке, а затем выполните такие шаги:# fsck -p # mount -a -t ufs # доступность /var/crash для записи # savecore /var/crash /dev/ad0s1b # exit # переход в многопользовательский режимЭти команды указывают savecore(8) извлечь дамп ядра из устройства /dev/ad0s1b и поместить его содержимое в каталог /var/crash. Не забудьте проверить, что в целевом каталоге /var/crash достаточно места для хранения дампа. Кроме того, не забудьте проверить правильность маршрута к вашему устройству подкачки, так как он, скорее всего, отличается от /dev/ad0s1b!
Рекомендуемым и определённо самым простым способом автоматизации формирования
аварийных образов является указание переменной dumpdev в
файле rc.conf(5).
| Пред. | Начало | След. |
| * DMA | Уровень выше | Отладка аварийного образа памяти ядра при помощи kgdb |
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.