Включение Kdump в Linux: дамп ядра при kernel panic

Уровень: Средний / Старший
Ориентировочное время: ~30 минут
Цель: Настроить захват дампов памяти kdump для kernel panic, что позволяет проводить надежный постмортем анализ сбоев в продакшене. Это руководство объясняет, как включить kdump в Linux, охватывая полную настройку linux crash dump от резервирования памяти до анализа vmcore.

Введение

Kernel panic останавливает систему, и без crash dump у вас нет никаких данных для работы. Kdump - стандартный фреймворк дампов памяти (crash dump) ядра Linux - решает это: он предварительно загружает ядро захвата (capture kernel) в зарезервированную память, и когда основное ядро испытывает панику, kexec загружает это ядро захвата для записи полного образа памяти (vmcore) на диск. В этом руководстве вы узнаете, как включить kdump в Linux для захвата dump при linux kernel panic на системах Ubuntu, Debian и RHEL. Мы покажем вам точно, как включить kdump на системах Linux, включая шаги постмортем анализа vmcore в Linux.

Что такое Kdump?

Kdump — это механизм создания дампов памяти ядра при сбоях, который использует kexec для загрузки вторичного ядра захвата из зарезервированной области памяти, когда основное ядро испытывает панику. Ядро захвата работает с ограниченной памятью (установленной параметром загрузки crashkernel) и записывает образ памяти сбойного ядра на диск как vmcore — полный файл дампа памяти, который можно проанализировать с помощью утилиты crash или gdb. Служба kdump (kdump.service на RHEL или kdump-tools.service на системах Debian) управляет загрузкой ядра захвата во время загрузки системы.

Основные компоненты:

• Kexec - системный вызов и инструмент пользовательского пространства, который загружает ядро захвата в зарезервированную память.
• Crashkernel - параметр загрузки, который сообщает основному ядру, сколько оперативной памяти зарезервировать для работы kdump (например, crashkernel=256M).
• Vmcore - выходной файл, содержащий полный дамп памяти, который по умолчанию записывается в /var/crash.
• /var/crash - каталог по умолчанию, где kdump хранит файлы vmcore после паники ядра.

Требования

Перед началом убедитесь, что выполнены следующие условия:

• Операционная система: Ubuntu 22.04/24.04 LTS, Debian 12/13 или RHEL/CentOS/AlmaLinux 9/10 (Протестировано и проверено на Ubuntu 24.04, Debian 13 и AlmaLinux 10)
• Доступ: sudo или root доступ к серверу
• RAM: Минимум 2 ГБ общей памяти. Kdump резервирует часть системной памяти (обычно 256 МБ) для ядра захвата — системам с малым объемом памяти может не хватить запаса.
• Дисковое пространство: Как минимум столько же свободного места в /var/crash, сколько в вашей системе оперативной памяти (vmcore может быть размером с физическую память)
• Необходимые знания: уверенное использование командной строки Linux, базовое редактирование файлов и знакомство с параметрами загрузки GRUB
• Окно для перезагрузки: Настройка параметра crashkernel требует перезагрузки для вступления в силу

Шаг 1: Установка пакетов kdump и kexec

Kdump полагается на kexec-tools (компонент kexec kdump пользовательского пространства) и специфичные для дистрибутива вспомогательные утилиты.

Ubuntu/Debian:

sudo apt update && sudo apt install kdump-tools kexec-tools crash -y

Во время интерактивной установки на Ubuntu может появиться запрос debconf с просьбой автоматически настроить параметр crashkernel. Выберите Да, если спросят. Если запрос не появляется (например, в неинтерактивном режиме), crashkernel настраивается автоматически через drop-in файл. Если вам нужно позже настроить значение, Шаг 2 охватывает ручную настройку.

RHEL/CentOS/AlmaLinux:

sudo dnf install kexec-tools crash -y

На системах на базе RHEL пакет kexec-tools предоставляет все необходимое: бинарный файл kexec, службу kdump и файлы конфигурации по умолчанию.

Шаг 2: Настройка параметра загрузки crashkernel

Параметр crashkernel сообщает ядру, сколько памяти нужно зарезервировать для kdump во время загрузки. Без этого резервирования ядру захвата негде будет работать. Понимание того, как правильно настроить значения параметра crashkernel, важно - слишком мало, и ядро захвата не загрузится; слишком много, и вы потратите впустую оперативную память продакшена.

2.1 Проверка текущей конфигурации

Сначала проверьте, установлен ли уже crashkernel:

cat /proc/cmdline | grep crashkernel

Если вывод содержит запись crashkernel=, параметр уже настроен. Вы можете проверить зарезервированный объем и перейти к Шагу 3, если он соответствует вашим потребностям.

2.2 Настройка параметра crashkernel на системах с GRUB

Ubuntu/Debian:

Прежде чем изменять основную конфигурацию GRUB, проверьте, существует ли уже drop-in файл:

cat /etc/default/grub.d/kdump-tools.cfg

Если пакет уже настроил crashkernel здесь, измените этот файл вместо этого, чтобы предотвратить дублирование записей в grub.cfg. В противном случае откройте основной файл по умолчанию GRUB:

sudo nano /etc/default/grub

Найдите строку GRUB_CMDLINE_LINUX_DEFAULT и добавьте параметр crashkernel. Для большинства продакшен-серверов с 4 ГБ или более оперативной памяти 256 МБ достаточно для резервирования памяти для kdump в Linux:

GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=256M"

Для серверов с менее чем 4 ГБ оперативной памяти используйте crashkernel=128M. Для систем с 64 ГБ или более рассмотрите crashkernel=512M. Вы также можете использовать синтаксис автоматического масштабирования crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M для динамической настройки значений параметра crashkernel на основе установленной оперативной памяти.

Сохраните и закройте файл, затем сгенерируйте конфигурацию GRUB:

sudo update-grub

RHEL/CentOS/AlmaLinux:

Для RHEL/AlmaLinux 8+ параметр crashkernel находится в GRUB_CMDLINE_LINUX (без _DEFAULT). Однако на современных системах, использующих BLS (Boot Loader Specification), самым безопасным и рекомендуемым способом обновления командной строки ядра является использование grubby вместо прямого редактирования /etc/default/grub:

sudo grubby --update-kernel=ALL --args="crashkernel=256M"

Если вам обязательно нужно изменить его вручную через конфигурации GRUB, отредактируйте /etc/default/grub и обновите GRUB_CMDLINE_LINUX. Затем сгенерируйте конфигурацию (пути отличаются в зависимости от режима загрузки):

# Для устаревших систем BIOS:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# Для систем UEFI (например, AlmaLinux):
sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

2.3 Перезагрузка для применения резервирования crashkernel

Резервирование памяти crashkernel вступает в силу только после перезагрузки:

sudo reboot

После того, как система снова заработает, убедитесь, что резервирование активно:

cat /proc/cmdline | grep crashkernel

Ожидаемый вывод включает:

crashkernel=256M

Также подтвердите, что память была действительно зарезервирована:

sudo dmesg | grep -i "crashkernel reserved"

Вы должны увидеть строку вроде:

crashkernel reserved: 0x... - 0x... (NNN MB)

Если резервирование не удалось (сообщение гласит "crashkernel reservation failed"), вам может потребоваться увеличить или уменьшить значение. Это распространенный шаг в устранении неполадок (troubleshooting) паники ядра Linux - ядро не смогло найти непрерывный блок запрошенного размера.

Шаг 3: Настройка службы kdump

Имея зарезервированную память, настройте, где и как kdump сохраняет vmcore.

3.1 Конфигурация RHEL/CentOS/AlmaLinux

Основной файл конфигурации — /etc/kdump.conf. Откройте его:

sudo nano /etc/kdump.conf

Критические директивы:

path /var/crash
core_collector makedumpfile -l --message-level 7 -d 31

• path /var/crash - устанавливает целевой каталог для vmcore. Все дампы сбоев попадают сюда.
• core_collector makedumpfile - сжимает дамп и фильтрует ненужные страницы. Флаг -d 31 исключает нулевые страницы, кэш, данные пользователя и свободные страницы - обычно уменьшая vmcore до 10-20% общей оперативной памяти.

3.2 Конфигурация Ubuntu/Debian

На системах на базе Debian конфигурация kdump-tools находится в /etc/default/kdump-tools. Откройте его:

sudo nano /etc/default/kdump-tools

Убедитесь, что установлены следующие строки:

USE_KDUMP=1
KDUMP_COREDIR="/var/crash"
KDUMP_CORE_COLLECTOR="makedumpfile -l --message-level 7 -d 31"

USE_KDUMP=1 включает службу kdump. Без этого ядро захвата не будет загружено при запуске системы.

Шаг 4: Включение и запуск службы kdump

Это последний шаг в том, как включить kdump в Linux. Включите службу kdump, чтобы ядро захвата загружалось автоматически при каждом запуске, завершая настройку kexec kdump в Linux.

Ubuntu/Debian:

sudo systemctl enable kdump-tools
sudo systemctl start kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl enable kdump
sudo systemctl start kdump

Проверьте, работает ли служба:

Ubuntu/Debian:

sudo systemctl status kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl status kdump

Ожидаемый вывод включает:

Active: active (exited)

Состояние "exited" является нормальным - служба kdump загружает ядро захвата в зарезервированную память и затем завершает работу. Она не работает как постоянный демон.

Шаг 5: Проверка и тестирование

5.1 Проверка готовности kdump

Убедитесь, что ядро захвата загружено и готово сработать при kernel panic:

cat /sys/kernel/kexec_crash_loaded

Ожидаемый вывод:

1

Значение 1 означает, что ядро захвата загружено. Значение 0 означает, что kdump не работает - вернитесь и проверьте состояние службы и резервирование crashkernel.

Вы также можете проверить, сколько памяти было выделено для резервирования памяти для kdump в Linux:

cat /sys/kernel/kexec_crash_size

Это возвращает резервирование в байтах.

5.2 Вызов тестового сбоя

Включите триггеры SysRq, затем вызовите сбой:

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-trigger

Система испытает панику. Если kdump настроен правильно, ядро захвата загружается, записывает vmcore в /var/crash, и система автоматически перезагружается.

5.3 Подтверждение захвата vmcore

После перезагрузки проверьте /var/crash на наличие дампа:

ls -lh /var/crash/

Ожидаемый вывод (формат зависит от дистрибутива):

Семейство RHEL (AlmaLinux/CentOS):

drwxr-xr-x 2 root root 4.0K May 23 14:00 127.0.0.1-2026-05-23-14:00:01/

Внутри этого каталога с временной меткой вы найдете vmcore (дамп памяти) и vmcore-dmesg.txt (журнал ядра).

Семейство Debian (Ubuntu/Debian):

drwxr-xr-x 2 root root 4.0K May 23 14:00 202605231400/

Внутри этого каталога файлы обычно называются dump.<timestamp> и dmesg.<timestamp>.

Проверьте внутри каталога:

ls -lh /var/crash/*/

Наличие этих файлов подтверждает, что ваш конвейер дампов памяти ядра Linux полностью работоспособен.

Шаг 6: Анализ файла vmcore

Захват дампа сбоя полезен только в том случае, если вы можете его прочитать. Утилита crash - это стандартный инструмент для анализа vmcore, на который полагаются администраторы Linux для устранения неполадок паники ядра Linux.

6.1 Установка debug ядра

Инструмент crash требует символов отладки (debug symbols) для той же версии ядра, которая испытала панику.

Ubuntu:

echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse" | sudo tee /etc/apt/sources.list.d/ddebs.list
sudo apt install ubuntu-dbgsym-keyring
sudo apt update
sudo apt install linux-image-unsigned-$(uname -r)-dbgsym

Debian:

echo "deb http://deb.debian.org/debian-debug/ $(lsb_release -cs)-debug main" | sudo tee /etc/apt/sources.list.d/debian-debug.list
sudo apt update
sudo apt install linux-image-$(uname -r)-dbg

RHEL/CentOS/AlmaLinux:

sudo dnf --enablerepo='*-debuginfo' install -y kernel-debuginfo-$(uname -r)

6.2 Открытие vmcore с помощью crash

Перед запуском crash проверьте наличие файла vmlinux, чтобы не запускать команду вслепую и сразу видеть, совпадают ли символы:

# RHEL/Debian:
ls -lh /usr/lib/debug/lib/modules/$(uname -r)/vmlinux

# Ubuntu:
ls -lh /usr/lib/debug/boot/vmlinux-$(uname -r)

Перейдите в каталог дампа сбоя и откройте vmcore (точная команда зависит от ОС):

RHEL/CentOS/AlmaLinux:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore

Debian:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/dump.*

Ubuntu:

sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/*/dump.*

Утилита crash загружается и переводит вас в интерактивную оболочку. Основные команды для первоначальной сортировки (triage):

bt          # backtrace задачи, вызвавшей панику
log         # буфер журнала ядра (то же, что dmesg на момент паники)
ps          # список процессов на момент сбоя
mod         # загруженные модули ядра
sys         # системная информация

Введите exit или quit, чтобы выйти из оболочки crash.

Откат изменений

Чтобы отменить настройку kdump и освободить зарезервированную память:

1. Остановите и отключите службу kdump:

Ubuntu/Debian:

sudo systemctl disable --now kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl disable --now kdump

2. Удалите параметр crashkernel:

Ubuntu/Debian:

Откройте drop-in конфигурационный файл:

sudo nano /etc/default/grub.d/kdump-tools.cfg

Удалите параметр crashkernel (если вы добавляли его в /etc/default/grub вручную, отредактируйте тот файл).

RHEL/CentOS/AlmaLinux:

Откройте файл GRUB по умолчанию:

sudo nano /etc/default/grub

Удалите crashkernel=256M из строки GRUB_CMDLINE_LINUX или GRUB_CMDLINE_LINUX_DEFAULT.

Сгенерируйте GRUB:

Ubuntu/Debian:

sudo update-grub

RHEL/CentOS/AlmaLinux:

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

3. Перезагрузите, чтобы освободить зарезервированную память:

sudo reboot

4. Удалите пакеты (необязательно):

Ubuntu/Debian:

sudo apt remove --purge kdump-tools kexec-tools crash -y

RHEL/CentOS/AlmaLinux:

sudo dnf remove kexec-tools crash -y

Решение проблем

Служба kdump не запускается

Проверьте журнал, чтобы узнать причину:

journalctl -xeu kdump

Частые причины:

• Нет резервирования crashkernel. Проверьте с помощью cat /proc/cmdline | grep crashkernel. Если отсутствует, повторите Шаг 2.
• Недостаточно зарезервированной памяти. Ядру захвата нужно достаточно оперативной памяти для инициализации и записи дампа. Попробуйте увеличить значение (например, crashkernel=512M).
• Конфликт Secure Boot. Некоторые конфигурации Secure Boot не позволяют kexec загружать неподписанные ядра. Либо подпишите ядро захвата, либо отключите Secure Boot в BIOS.

Vmcore не записывается после паники

• Дисковое пространство. Убедитесь, что /var/crash имеет достаточно свободного места. Vmcore может приближаться к размеру физической оперативной памяти (до сжатия makedumpfile).
• Неверный путь. Убедитесь, что path в /etc/kdump.conf (или KDUMP_COREDIR в /etc/default/kdump-tools) указывает на доступную для записи, смонтированную файловую систему.
• Отказ SELinux. На системах RHEL проверьте ausearch -m avc -ts recent на наличие отказов, связанных с kdump.

Система зависает вместо захвата дампа

Это обычно указывает на проблему с оборудованием или драйвером, которая предотвращает переход kexec kdump в Linux. Попробуйте добавить irqpoll nr_cpus=1 reset_devices к командной строке ядра kdump в /etc/sysconfig/kdump (RHEL) или /etc/default/kdump-tools (Debian) как KDUMP_CMDLINE_APPEND.

Заключение

Вот и все. Crashkernel резервирует память, служба kdump загружает ядро захвата во время запуска системы, и при дампе паники ядра Linux vmcore оказывается в /var/crash - готовой к работе конфигурации linux crash dump, которой вы можете доверять. Теперь у вас есть рабочая система для автоматического включения захвата дампов сбоев kdump в Linux; для более глубокого устранения неполадок паники ядра Linux передайте vmcore в crash и начните с backtrace.

Версия документа: 1.0
Последнее обновление: Май 2026
Владелец: Команда технической документации