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

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

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

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

Для 64-битных систем в таких случаях может помочь [https://en.wikipedia.org/wiki/Kdump_(Linux) kdump]. В ядре Linux есть '''kexec''' - механизм, позволяющий загрузить в память ещё одно ядро и передать ему управление. '''Инструменты kdump''' используют это, чтобы сохранить журнал ядра (dmesg) и дамп памяти ядра.

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

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

1. Во-первых, - установить kexec-tools:
<pre>urpmi kexec-tools</pre>
Нужна версия 2.0.15-5 или новее.

2. Также стоит проверить версию dracut:
<pre>rpm -qi dracut</pre>
Нужна версия 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'''. Затем стоит перезагрузить систему.

Проверьте теперь, что память для "резервного" ядра выделена:
<pre>dmesg | grep -i crashkernel</pre>
Если в выводе этой команды есть что-то вроде ''"Reserving 256MB of memory at <...> for crashkernel"'', значит, память выделена.

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

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

Готово.

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

<pre># 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
</pre>

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 всё-таки будет работать.