Сохранение отчётов о падениях ядра с помощью kexec/kdump

Материал из Rosalab Wiki
Версия от 00:30, 7 октября 2017; Euspectre (обсуждение | вклад) (Новая страница: «== Чем полезны kexec и kdump == Если в ядре ROSA Linux происходит сбой, система может перестать реаги…»)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Чем полезны kexec и kdump

Если в ядре ROSA Linux происходит сбой, система может перестать реагировать на действия пользователя, "зависнуть". Подключиться к системе удалённо, например, по SSH, при этом тоже не всегда возможно. Обычно в такой ситуации помогает только reset (впрочем, иногда всё же работает и alt+sysrq+{r,e,i,s,u,b}).

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

Для 64-битных систем в таких случаях может помочь kdump. В ядре Linux есть kexec - механизм, позволяющий загрузить в память ещё одно ядро и передать ему управление. Инструменты kdump используют это, чтобы сохранить журнал ядра (dmesg) и дамп памяти ядра.

Установка и настройка kdump

В 64-битном варианте ROSA, начиная с ROSA R9, включить kdump можно так.

1. Во-первых, - установить kexec-tools:

urpmi kexec-tools

Нужна версия 2.0.15-5 или новее.

2. Также стоит проверить версию dracut:

rpm -qi dracut

Нужна версия 046 или новее. На данный момент (2017-10-06) в официальных репозиториях такой нет, взять можно отсюда: http://abf-downloads.rosalinux.ru/import_personal/container/2899261/x86_64/main/release/

3. В список параметров загрузки ядра нужно добавить crashkernel=256M - это укажет системе, что нужно выделить 256Mb памяти для "резервного" ядра, которому будет передано управление при сбое. Если кажется, что 256Mb - слишком много, можно поэкспериментировать с меньшими значениями, но если взять слишком маленький объём памяти для "резервного" ядра, оно может не загрузиться.

crashkernel=256M можно добавить в список параметров ядра при загрузке (лучше не в самый конец, можно - после quiet или перед resume). Если хотите держать kdump включенным постоянно, то можно вписать crashkernel=256M в список GRUB_CMDLINE_LINUX_DEFAULT в /etc/default/grub, а затем вызвать update-grub2. Затем стоит перезагрузить систему.

Проверьте теперь, что память для "резервного" ядра выделена:

dmesg | grep -i crashkernel

Если в выводе этой команды есть что-то вроде "Reserving 256MB of memory at <...> for crashkernel", значит, память выделена.

4. Включите kdump:

systemctl start kdump

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

Если хотите, чтобы служба kdump автоматически стартовала при загрузке системы, выполните ещё

systemctl enable kdump

Готово.

Проверка

При желании теперь можно проверить, как система отреагирует на падение ядра:

echo c > /proc/sysrq-trigger

Эта команда вызовет падение ядра. Если выше kdump был запущен правильно, то управление будет передано "резервному" ядру. Оно, в свою очередь, сохранит dmesg и дамп памяти основного ядра - по умолчанию, в подкаталоге каталога /var/crash/. Затем оно автоматически перезагрузит систему. После этой перезагрузки можно посмотреть, что было сохранено:

# ls -lR /var/crash/
127.0.0.1-2017-10-05-22:11:35/:
-rw------- 1 root root 59749078 окт  5 22:11 vmcore
-rw-r--r-- 1 root root    38744 окт  5 22:11 vmcore-dmesg.txt

vmcore - заархивированный дамп памяти ядра, vmcore-dmesg.txt - журнал ядра на момент падения.

Расширенные настройки

О настройках kdump (напр., куда именно сохранять данные, на локальную машину или передавать по сети и т.п.) см. man kdump.conf.

Что делать, если kdump не сохраняет данные

К сожалению, на некоторых системах kdump может не отработать правильно. Рецепта на все случаи жизни тут нет.

Для начала проверьте, что память для "резервного" ядра была выделена (см. выше) и служба kdump стартовала без ошибок (см. systemctl status kdump).

Если выделяли меньше 256Mb, увеличьте это значение.

Если система при сбое ядра просто "зависает", никаких сообщений не выдаёт и после этого не перезагружается автоматически в течение 3-5 минут, возможно, что-то пошло не так при загрузке "резервного" ядра.

Тут разве что можно попробовать убрать "reset_devices" из KDUMP_COMMANDLINE_APPEND в /etc/sysconfig/kdump, удалить initrd, созданные kdump'ом (rm /boot/*kdump*), затем перезапустить службу kdump (systemctl restart kdump) и надеяться, что при следующих сбоях ядра kdump всё-таки будет работать.