Ответные действия при панике


http://www.mebel-styl.ru/ продажа кроватей для гостиниц.

Если система впала в панику, прежде всего надо скопировать сообщения о неполадках. Поскольку в случае паники FreeBSD стандартные способы копирования данных на вашей машине недоступны — система не позволит войти в нее с помощью SSH и запустить даже такие простые команды, как script(1). Консоль может быть намертво заблокирована либо можно «застрять» в отладчике. Но в любом случае вы должны иметь сообщение об ошибке.

FreeBSD не всегда автоматически перезагружалась после паники, раньше в этом случае просто выводилось сообщение. Впервые увидев панику, я стал искать бумагу и карандаш. Нашел старый конверт и огрызок карандаша, которым можно было писать под определенным углом, и пополз между серверной стойкой и необработанной кирпичной стеной. Я удерживал равновесие, одной рукой не давая упасть шестидюймовому черно-белому монитору, а другой прижимая к стене конверт. Очевидно, в экстренных ситуациях у меня может отрастать третья рука, так как мне все же удалось записать сообщение о неполадках на конверте. Наконец, поцарапанный и согнутый в три погибели, я задним ходом выбрался из-за стойки и победоносно отправил это сообщение по электронной почте. Уж конечно, первоклассные разработчики FreeBSD посмотрят на всю эту абракадабру и точно скажут, что случилось.

Вскоре я понял, что у FreeBSD нет специалистов, способных решить мою проблему. Вместо этого я получил короткий ответ: «Можете прислать вывод обратной трассировки?» Когда я спросил, как это сделать, меня отправили читать справочное руководство (глава 1). К счастью, паника оказалась легко воспроизводима, единственное, что требовалось, — это воссоздать ошибку при входе клиента в систему. Остаток дня я провел в борьбе с последовательной консолью и дампами ядра.

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

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

Подготовка

Анализировать панику можно разными способами; я предпочитаю записывать дамп памяти на диск для дальнейшей спокойной обработки. Вам необходимо пространство свопинга (область подкачки), размером немного превосходящее память, занимаемую ядром. Несмотря на то что вам может потребоваться полный дамп оперативной памяти, в большинстве случаев дамп ядра FreeBSD 7.0 занимает меньше половины гигабайта. Если вы используете нечто требующее выделения большого объема памяти в ядре, например экспериментальную поддержку файловой системы ZFS, размер дампа ядра увеличится. Если область подкачки недостаточно велика, надо либо переустановить систему, либо добавить жесткий диск с областью подкачки достаточного размера. (Помните, что я говорил об этом в главе 2? Вы еще не жалеете, что не слушали меня тогда?) Наличие в разделе /var свободного пространства, достаточного для дампа ядра, полезно, но необязательно.

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

Процесс получения аварийного дампа примерно таков: если система сконфигурирована правильно, то при аварии она сохранит копию оперативной памяти. Эта копия называется дампом. Система не может сохранить дамп в файле. С одной стороны, потому что при аварии ядро ничего не знает о файлах, с другой — файловая система может быть повреждена или попытка записи может повредить ее. Однако ядро знает о разделах, поэтому оно может записать дамп в раздел. Проще всего записать дамп в раздел свопинга, предназначенный для временного хранения содержимого памяти. По умолчанию FreeBSD сохраняет дамп в первом разделе свопинга, размещая его как можно ближе к концу раздела. Как только дамп будет сохранен, система перезагрузит компьютер.

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

Как только FreeBSD обретет файловую систему, где можно будет сохранить дамп памяти, она запустит программу savecore(8), которая скопирует его в подходящую файловую систему, удалит дамп из пространства свопинга и продолжит перезагрузку. Теперь у вас есть файл с дампом ядра, который можно проанализировать.

Настройка вывода аварийного дампа

По умолчанию FreeBSD сохраняет дамп в первом доступном разделе свопинга и при каждой перезагрузке проверяет пространство свопинга на наличие дампа. При необходимости такое поведение системы можно изменить.

Очевидно, вам может потребоваться сохранять дамп в другом разделе свопинга, особенно после добавления нового жесткого диска специально для того, чтобы создать раздел свопинга, способный хранить дамп. Определите устройство дампа с помощью переменной dumpdev в файле /etc/rc.conf:

dumpdev="/dev/ad4s1b"

Не забудьте перечислить в файле /etc/fstab всех разделы свопинга.

Программа savecore(8) автоматически сохраняет дамп ядра в каталоге /var/crash. Однако если раздел /var имеет недостаточный размер для хранения дампа, укажите другой каталог в переменной dumpdir в файле rc.conf:

dumpdir="/usr/crash"

Последовательные консоли и паника

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

Несмотря на то что savecore(8) обладает некоторыми дополнительными возможностями, такими как возможность сжатия файла, в современных системах они обычно не используются.

Теперь, имея отладочное ядро и устройство сохранения дампа, вы готовы к аварийным ситуациям, насколько это возможно.

Отладка ядра

В процессе сборки ядра FreeBSD в него включается большой объем отладочной информации. Вы найдете первичную отладочную информацию в файлах символов (symbols), обеспечивающих отображение между машинным и исходным кодом. Кроме того, это отображение содержит полный список номеров строк исходного кода, поэтому разработчик может точно выяснить, где произошли неполадки. Без этой информации разработчику пришлось бы соотносить дамп ядра и исходный код вручную. Примерно так собирают пазл из миллиона кусочков, когда под рукой нет картинки-образца и неизвестно, все ли кусочки в наличии. Это нелегкая задача. Она еще труднее, если разработчик, который должен предложить решение, является добровольцем. Символы имеют важное значение.

Наличие отладчика в ядре облегчает процесс отладки, если у вас есть доступ к консоли или последовательная консоль к удаленной машине. Отладку можно вести полностью в автономном режиме, но иногда наличие отладчика упрощает поиск причин паники.

Чтобы сохранить отладочную информацию и включить отладчик в ядро, добавьте в конфигурацию ядра следующие строки:

makeoptions DEBUG=-g
options KDB
options KDB_TRACE
options DDB

После добавления опции DDB в ядро FreeBSD больше не будет автоматически перезагружаться после паники. Что вам больше подходит — чтобы система сама перезагружалась после паники или ждала вашего вмешательства? В случае удаленной системы вы почти наверняка захотите сохранить дамп и автоматически перезагрузить машину после паники, но если вы находитесь рядом с консолью, то, возможно, захотите выполнить перезагрузку вручную.

Для автоматической перезагрузки используйте параметр ядра KDB_UNATTENDED:

options KDB_UNATTENDED

Этот параметр предписывает FreeBSD автоматически перезагрузиться после паники, даже если в конфигурации ядра присутствует параметр DDB. После паники на экране появится сообщение, предлагающее нажать клавишу пробела, чтобы войти в отладчик; если этого не сделать, система перезагрузится через 15 секунд.

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