Kernel panic на VDS: сбор диагностики через kdump и анализ vmcore

Kernel panic на Linux — это критическая ошибка ядра, после которой система останавливается или уходит в перезагрузку. На VDS это часто выглядит как внезапный ребут (если настроен watchdog/автовосстановление) или «зависание» в консоли. Главная проблема расследования — после перезапуска не остаётся артефактов: ни дампа памяти, ни последних сообщений ядра.

Ниже — практичный пайплайн диагностики: быстро отличаем panic от похожих проблем, включаем kdump, подбираем crashkernel, проверяем сохранение vmcore, настраиваем постоянные логи journalctl и собираем аппаратные признаки через rasdaemon/mcelog. Цель — получить доказательства, а не «угадывать» причину.

Что именно собирать при kernel panic

Для нормального разбора обычно нужны три слоя данных:

• Логи ядра вокруг события: вывод journalctl по предыдущей загрузке и kernel-логи (-k), если они успели записаться.

• Дамп памяти: файл vmcore, который создаёт kdump (часто это единственный шанс понять первопричину при редких падениях).

• Аппаратные и низкоуровневые сигналы: MCE/EDAC, ошибки дисковой подсистемы, таймауты, сбои драйверов виртуализации, проблемы сети.

Дальше по тексту инструменты намеренно «разделены по источникам правды»: journalctl даёт общую картину, kdump/vmcore фиксируют состояние памяти, rasdaemon/mcelog подсвечивают железо (или хост), а netconsole помогает поймать последние строки ядра «в полёте».

Сначала — быстрый triage: это точно kernel panic?

Под «kernel panic» часто попадают другие сценарии: OOM и массовое убийство процессов, зависание I/O, рестарт по внешней причине, падение критичного user-space демона. Перед тем как тратить время на kdump, проверьте базовые сигналы.

Проверяем предыдущую загрузку и причины ребута

Сразу после восстановления доступа:

uname -a
who -b
uptime

Дальше смотрим логи предыдущей загрузки (важно: -b -1):

journalctl -b -1 -p warning..alert --no-pager
journalctl -b -1 -k --no-pager

Если это был именно panic, часто встречаются строки вида Kernel panic - not syncing, backtrace, упоминание модуля/подсистемы, а конец лога выглядит «оборванным».

Проверяем, не это ли OOM и давление по памяти

OOM почти всегда оставляет читаемые следы:

journalctl -b -1 --no-pager | grep -E "Out of memory|oom-killer|Killed process" --line-buffered

Если используется systemd-oomd, он тоже может завершать процессы:

journalctl -b -1 -u systemd-oomd --no-pager

OOM в user-space и kernel panic — разные истории. При OOM вы почти всегда найдёте объясняющие записи в логах. При panic без дампа памяти легко остаться с ситуацией «вчера работало, сегодня ребут».

Если у вас есть подозрения, что проблему провоцирует конфигурация/нагрузка на ресурсы, полезно заранее сверить план и лимиты VDS (CPU/RAM/диск) и при необходимости пересобрать профиль нагрузки. В тему может пригодиться материал про подбор конфигурации: как выбрать VDS по CPU и RAM под реальную нагрузку.

Включаем kdump: базовая схема

kdump работает так: при падении основного ядра запускается второе, минимальное «crash kernel» (через kexec), которое сохраняет дамп памяти в файл vmcore на диск или по сети. Для VDS это один из самых надёжных способов получить материал для анализа, потому что при панике обычная запись логов может уже не работать.

Проверяем, зарезервирована ли память под crash kernel

Сначала смотрим параметры загрузки:

cat /proc/cmdline

И косвенно — что память действительно зарезервирована:

grep -i crash /proc/iomem

Если параметра crashkernel в командной строке нет, kdump не сможет выделить память под второе ядро.

Установка пакетов

Debian/Ubuntu:

apt update
apt install -y kdump-tools

RHEL/Alma/Rocky:

dnf install -y kexec-tools

Дальше логика одинаковая: задать crashkernel, включить сервис kdump и убедиться, что crash kernel реально готов к запуску.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Настройка crashkernel: сколько памяти резервировать на VDS

crashkernel — параметр ядра, который резервирует часть RAM под «второе ядро» и запись дампа. Типовые ошибки две: зарезервировать слишком мало (kdump включён, но vmcore не пишется), или слишком много (на небольшой VDS вы внезапно теряете полезную память под нагрузкой).

Практичные ориентиры

Точные цифры зависят от дистрибутива, версии ядра, количества модулей, storage/сети и наличия специфичных драйверов. Как стартовые значения для типовой VDS:

• RAM 2–4 ГБ: crashkernel=256M

• RAM 8–16 ГБ: crashkernel=512M

• RAM 32–64 ГБ: crashkernel=768M или 1G

Если у вас сложная сеть, шифрование, iSCSI, много модулей или нестандартный initramfs — закладывайте запас вверх.

Как задать crashkernel через GRUB

Добавьте crashkernel=... к параметрам ядра в /etc/default/grub (обычно GRUB_CMDLINE_LINUX_DEFAULT или GRUB_CMDLINE_LINUX).

grep -n "GRUB_CMDLINE_LINUX" /etc/default/grub

После правки пересоберите конфиг GRUB.

Debian/Ubuntu:

update-grub

RHEL-подобные:

grub2-mkconfig -o /boot/grub2/grub.cfg

Перезагрузитесь и проверьте, что параметр применился:

reboot

cat /proc/cmdline

Проверка: kdump реально поднялся

Debian/Ubuntu:

systemctl status kdump-tools --no-pager
kdump-config show

RHEL-подобные:

systemctl status kdump --no-pager

Дополнительно полезно проверить сообщения ядра о резервировании памяти:

dmesg | grep -i crashkernel --line-buffered

Куда сохранять vmcore и почему место заканчивается внезапно

vmcore может быть большим: в худшем случае близким к объёму RAM. Многие системы применяют фильтрацию и сжатие, но планировать место всё равно нужно заранее.

Проверяем путь сохранения

Debian/Ubuntu (kdump-tools):

kdump-config show

RHEL-подобные: смотрим /etc/kdump.conf без комментариев и пустых строк:

grep -v "^#" /etc/kdump.conf | sed "/^*$/d"

Для VDS чаще выбирают локальный каталог (например, /var/crash), а затем уже выгружают артефакты на отдельную машину или в хранилище.

Проверяем свободное место заранее

df -hT /var /var/crash 2>/dev/null

Если /var маленький, дамп может не записаться или забить диск и осложнить восстановление. Практика: держать запас хотя бы под 1–2 дампа и продумать, где и как вы храните старые vmcore.

Тестируем kdump безопасно

Без теста вы узнаете, что «не пишется дамп», только в момент реальной аварии. Лучше проверить заранее, в окно работ.

Проверка загрузки crash kernel без падения

На Debian/Ubuntu часто достаточно:

kdump-config test

И проверок статуса службы. Идея теста одна: crashkernel зарезервирован, initramfs для crash kernel собран, механизм готов.

Тестовая паника через SysRq (только если понимаете последствия)

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

Разрешаем SysRq временно:

sysctl -w kernel.sysrq=1

Инициируем крэш:

echo c > /proc/sysrq-trigger

После загрузки проверяем, что дамп появился:

ls -lah /var/crash 2>/dev/null
find /var/crash -maxdepth 3 -type f -name "vmcore*" -ls 2>/dev/null

Анализируем vmcore: минимально полезный уровень

Пытаться «прочитать vmcore глазами» бессмысленно: обычно дамп анализируют утилитой crash с подходящими символами (vmlinux с debug symbols). На проде удобный подход такой: сохранить дамп и метаданные на VDS, а разбирать на отдельной машине, чтобы не нагружать сервер.

Что сохранить вместе с vmcore

• vmcore и сопутствующие файлы (например, vmcore-dmesg.txt, если он формируется)

• версию ядра: uname -r

• список пакетов ядра (Debian/Ubuntu): dpkg -l | grep -E "linux-image|linux-modules"

• командную строку загрузки: cat /proc/cmdline

• логи: journalctl -b -1 -k и journalctl -b -1

Где искать быстрые ответы без глубокой отладки

Даже без полноценного разбора в crash иногда удаётся классифицировать проблему по логам предыдущей загрузки:

• паника в конкретном модуле или подсистеме (net/block/fs/virtio)

• повторяющийся Oops/BUG/backtrace

• I/O таймауты, reset контроллера, ошибки файловой системы

• MCE/EDAC события, похожие на проблемы памяти/CPU на стороне хоста

Логи: journalctl, persistent storage и частые ловушки

Если journald хранит журналы только в RAM, после ребута вы потеряете самое интересное. Проверьте постоянное хранение.

Включаем persistent journald

Проверяем, существует ли каталог:

ls -ld /var/log/journal 2>/dev/null

Если его нет — создаём и применяем tmpfiles, затем перезапускаем journald:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

Теперь journalctl -b -1 станет полезнее. Но при настоящем panic всё равно возможны «дыры» — именно поэтому kdump остаётся главным артефактом.

Аппаратные и «почти аппаратные» ошибки: rasdaemon и mcelog

Даже в виртуальной среде могут проявляться признаки проблем хоста (например, MCE). На современных системах чаще используют rasdaemon; mcelog — более старый инструмент, который не всегда актуален на новых ядрах и платформах.

rasdaemon: установка и просмотр

Пример для Debian/Ubuntu:

apt install -y rasdaemon
systemctl enable --now rasdaemon

Смотрим события:

journalctl -u rasdaemon --no-pager

И полезный grep по kernel-логам:

journalctl -k --no-pager | grep -iE "mce|edac|hardware error|ras" --line-buffered

mcelog (если он у вас используется)

systemctl status mcelog --no-pager
journalctl -u mcelog --no-pager

Если видите MCE/Hardware Error — фиксируйте время и частоту событий: это сильный аргумент, что проблема не в приложении, а ниже по стеку.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

netconsole: когда нужно поймать последние строки ядра «в полёте»

netconsole отправляет сообщения ядра по UDP на удалённый приёмник. Это полезно, когда panic происходит так рано, что journald не успевает ничего записать, а kdump не получается настроить или он сам падает.

Что важно учесть до включения

• Нужен отдельный приёмник логов в сети, который будет слушать UDP-порт.

• Это не замена kdump: вы получите текст последних сообщений, но не дамп памяти.

• Если падает сетевой драйвер, netconsole может не успеть отправить логи.

Точная настройка зависит от дистрибутива и схемы сети. После включения обязательно проверьте, что тестовые сообщения доходят, и задокументируйте настройки (адрес/интерфейс/порт), чтобы не вспоминать их во время инцидента.

systemd-coredump: не про kernel panic, но часто рядом

systemd-coredump собирает дампы процессов user-space. Он не поймает падение ядра, но помогает, когда «сервер лёг» из-за падения критичного демона или когда есть гипотеза, что панику провоцирует конкретное приложение (нагрузка, особенности сетевого трафика, работа с диском).

Посмотреть список дампов:

coredumpctl list --no-pager

И детали по выбранному событию:

coredumpctl info --no-pager

Типовые причины kernel panic на VDS и как их подтверждать

Без vmcore это почти всегда гадание. Но с логами и дампом можно быстро разложить проблему по классам и понять, куда копать дальше.

Баг ядра или модуля (включая virtio)

Признаки: backtrace указывает на конкретную подсистему (net/block/fs), проблема началась после обновления ядра, включения модуля или смены конфигурации. Что делать:

• зафиксировать версию ядра и время, когда начались падения;

• при возможности временно загрузиться на предыдущем ядре и проверить, исчезает ли проблема;

• собрать vmcore и journalctl -b -1 -k для предметного анализа.

Проблемы памяти/CPU на хосте (MCE)

Признаки: Hardware Error, MCE/EDAC, события в rasdaemon/mcelog. Что делать: сохранить выжимку логов, время, частоту событий и приложить к обращению в поддержку/к провайдеру.

Дисковая подсистема: timeouts, resets, corruption

Признаки: перед падением в kernel-логах появляются I/O error, reset, blk_update_request, таймауты. Что делать:

• собрать логи по блоку/ФС из journalctl -b -1 -k;

• планово проверить файловую систему (с учётом её типа и режима работы);

• убедиться, что vmcore пишется не на проблемный том (иначе дамп может не сохраниться).

Чеклист: чтобы следующий kernel panic не был «слепым»

1. Включить постоянное хранение журналов journald на диск.

2. Настроить kdump и параметр crashkernel, проверить резервирование памяти.

3. Проверить место под vmcore и правила хранения/удаления старых дампов.

4. Протестировать kdump в контролируемых условиях (минимум через kdump-config test или аналог).

5. Поставить rasdaemon (и при необходимости mcelog) для фиксации MCE/EDAC.

6. Если panic ранний или kdump не взлетает — настроить netconsole на отдельный приёмник.

Что подготовить для дальнейшего разбора (или для передачи в поддержку)

Чтобы расследование не превратилось в бесконечный обмен «пришлите ещё вот это», заранее соберите пакет артефактов:

• время инцидента (UTC и локальное) и что происходило на сервере (деплой, бэкап, пик нагрузки);

• journalctl -b -1 -k и journalctl -b -1 -p warning..alert;

• версия ядра и параметры загрузки: uname -r, cat /proc/cmdline;

• путь к vmcore, размер, контрольная сумма (и желательно архив/сжатие при передаче);

• события rasdaemon/mcelog (если были);

• краткое резюме наблюдений: «перед падением были I/O timeouts», «panic после обновления ядра», «в логах есть MCE».

С таким набором у вас появляется реальный шанс быстро локализовать проблему (ядро/модуль/диск/память) или корректно эскалировать её на уровень инфраструктуры.