Архитектура аварийного сохранения дампов ядра Linux (Kdump & Kexec)

При возникновении неустранимого критического сбоя ядра Linux (Kernel Panic, Hard Lockup, Oops, Machine Check Exception) операционная система не может продолжать нормальное функционирование и мгновенно зависает или перезагружается. Механизм Kdump базируется на системном загрузчике Kexec (Kernel Execution): при старте основной ОС резервируется изолированный сегмент оперативной памяти (Crashkernel). В момент падения основного ядра управление мгновенно передается запасному легковесному Capture Kernel, минуя аппаратную перезагрузку через BIOS/UEFI. Запасное ядро инициализирует минимальный набор драйверов, копирует содержимое оперативной памяти упавшей системы в файл /var/crash/vmcore (или на удаленный NFS/SSH сервер) и перезагружает сервер.

Бизнес-риски при отсутствии настроенного Kdump

Невозможность расследования причин внезапных ночных перезагрузок критических серверов, циклические аппаратные сбои в продакшене, многомесячные простои из-за невыявленных багов в кастомных драйверах ядра или модулях виртуализации KVM/OpenStack.

Компоненты стека анализа Kernel Crash Dump

Пошаговый регламент развертывания, тестирования и анализа Kdump

Шаг 1: Резервирование памяти crashkernel в параметрах загрузчика GRUB

Отредактируйте параметры запуска ядра в загрузчике:

# 1. Откройте конфигурационный файл GRUB:
sudo nano /etc/default/grub

# 2. Добавьте параметр crashkernel в строку GRUB_CMDLINE_LINUX_DEFAULT:
# Для серверов с RAM от 4G до 64G рекомендуется 256M или 512M (либо crashkernel=auto в RHEL):
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash crashkernel=512M"

# 3. Обновите конфигурацию GRUB:
sudo update-grub    # Для Ubuntu / Debian
# sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # Для RHEL / Rocky / AlmaLinux

# 4. Перезагрузите сервер для резервирования сегмента памяти:
sudo reboot

Шаг 2: Установка и активация службы Kdump

# Для Ubuntu / Debian:
sudo apt install -y kexec-tools kdump-tools makedumpfile
# Проверка статуса готовности:
sudo kdump-config status
# Ожидаемый вывод: current state: ready to kdump

# Для RHEL / AlmaLinux / Rocky Linux:
sudo dnf install -y kexec-tools crash
sudo systemctl enable --now kdump
sudo kdumpctl status
# Ожидаемый вывод: kdump: Kdump is operational

Шаг 3: Тестовая провокация Kernel Panic (SysRq Trigger)

Внимание: команда немедленно обрушит операционную систему! Выполняйте строго на тестовом стенде!

# Включение магических клавиш SysRq:
sudo sysctl -w kernel.sysrq=1

# Принудительный вызов Kernel Crash:
sudo bash -c 'echo c > /proc/sysrq-trigger'

# Сервер уйдет в перезагрузку через Capture Kernel. После старта проверьте наличие файла vmcore:
ls -lh /var/crash/*/vmcore

Шаг 4: Анализ дампа с помощью утилиты Crash

Для детального анализа установите отладочные символы ядра (vmlinux):

# 1. Запуск анализатора Crash:
sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/2025-03-10-16\:00/vmcore

# 2. В интерактивной консоли Crash выполните базовые команды:
# Вывод общей информации о падении (PANIC строка, процесс-виновник, регистры):
crash> sys

# Вывод трассировки стека упавшего ядра (Backtrace):
crash> bt

# Просмотр системного буфера сообщений (dmesg) в момент краша:
crash> log | tail -n 50

# Просмотр списка процессов в памяти на момент падения:
crash> ps

# Вывод упавшей структуры struct task_struct:
crash> struct task_struct [адрес_из_bt]

Типовые ошибки администраторов

• Недостаточный размер crashkernel: Выделение всего 64M памяти на современных серверах с терабайтами RAM приводит к тому, что запасному ядру не хватает памяти даже для инициализации контроллера NVMe, и дамп не сохраняется.
• Переполнение корневого раздела: Файл vmcore сжимается утилитой makedumpfile -l -d 31, но все равно может весить от 2 до 20 Гб. Всегда монтируйте /var/crash на отдельный вместительный раздел или сетевое хранилище NFS.