Сохранение отчётов о падениях ядра с помощью kexec/kdump
Содержание
Чем полезны 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 всё-таки будет работать.
