kdump — инструмент для анализа причин сбоев ядра

Минимальные требования
Обновление и установка пакетов
Оценка и настройка резервирования памяти для ядра kdump
Оценка и настройка размера дампа
Настройка места сохранения файлов дампа
Настройка действия по результату создания дампа
Запуск службы kdump и проверка её статуса
Тестирование работы kdump
Утилита kdumpctl
Файл конфигурации kdump.conf
Проблемы и решения

Окружение

• Версия ОС: 8
• Конфигурация ОС: Рабочая станция, Сервер графический
• Редакция ОС: Стандартная, Образовательная
• Версия ПО: dracut-059-10, kexec-tools-2.0.27-2

Kdump — это стандартный механизм Linux, предназначенный для создания дампа (снимка) содержимого оперативной памяти системы в момент сбоя ядра (kernel panic). Основной целью механизма kdump является сохранение состояния системы в момент сбоя для последующего анализа и выявления причин аварии. Механизм kdump основан на технологии kexec, которая позволяет загружать новое ядро Linux напрямую из работающей системы без прохождения полного цикла инициализации BIOS/UEFI.

Работа kdump происходит в несколько этапов:

1. Подготовка окружения. В основной системе (первичное ядро) настраивается и резервируется область оперативной памяти, называемая crashkernel. В этой области хранится минимальное аварийное ядро и initramfs, которые будут использованы при сбое.

2. Сбой ядра (Kernel Panic). При возникновении критической ошибки ядра система вызывает механизм kdump. Первичное ядро передаёт управление аварийному ядру (crash kernel), которое загружается с помощью kexec.

3. Запуск аварийного ядра. Аварийное ядро запускается в изолированной зарезервированной области памяти, что предотвращает перезапись данных из основной памяти. После загрузки оно получает доступ к памяти основной системы и сохраняет её содержимое (дамп памяти) в указанный файл или на указанный носитель.

4. Сохранение дампа. Настройка действия по результату создания дампа. Дамп памяти (обычно в формате vmcore) сохраняется в каталог /var/crash/. Каталог для сохранения можно указать самостоятельно. Впоследствии этот файл можно проанализировать с помощью инструментов, таких как crash или gdb, чтобы определить причину сбоя ядра.

Минимальные требования

Минимальные требования к окружению:

• набор инструментов dracut — dracut-056-9 и выше;

• механизм kexec — kexec-tools-2.0.27 и выше.

Обновление и установка пакетов

При использовании в системе пакетов dracut и kexec более ранних версий, чем указано в пункте «Минимальные требования», выполните их обновление (потребуются права администратора):

sudo dnf update

В случае, если в системе пакеты dracut и kexec не установлены, выполните команду установки (потребуются права администратора):

sudo dnf install dracut kexec-tools

Оценка и настройка резервирования памяти для ядра kdump

Для оценки необходимого размера резервирования памяти для аварийного ядра и initramfs выполните команду:

sudo kdumpctl estimate

kdump: Rebuilding /boot/initramfs-6.1.128-2.el7.3.x86_64kdump.img
Reserved crashkernel:    0M
Recommended crashkernel: 192M

Kernel image size:   46M
Kernel modules size: 10M
Initramfs size:      32M
Runtime reservation: 64M
Large modules:
    cfg80211: 1130496
    8821cu: 2666496
    8821ce: 2015232
WARNING: Current crashkernel size is lower than recommended size 192M.

В выводе команды представлена основная информация о результате оценки:

• сообщение kdump о том, что в каталоге /boot/ произведена сборка initramfs-образа kdump для аварийного ядра;

• Reserved crashkernel — размер текущего резервирования ядра (будет нулевым, если текущая загрузка ОС производилась без указания параметра ядра crashkernel);

• Recommended crashkernel — рекомендуемый размер резервирования с учётом параметров данной системы (размера ядра, образа initrd, объёма оперативной памяти).

Командой также выведены размеры составляющих рекомендуемого объема резервирования:

• Kernel image size — размер ядра;

• Initramfs size — размер initramfs;

• Runtime reservation — резервирование для обеспечения запуска процессов среды аварийного ядра;

• Large modules — имена и размеры самых объёмных модулей ядра.

Управление размером выделяемой резервной памяти производится через передачу ядру параметра crashkernel. Допустимо указание размерности буквами K (килобайты), M (мегабайты), G (гигабайты), следующей сразу за числом (без пробелов).

Возможные форматы значений параметра crashkernel:

• Пример с указанием только области резервирования размером 192 Мб:

  crashkernel=192M

• Для некоторых систем требуется оставлять свободным определённый фиксированный диапазон памяти. Смещение начала области резервирования указывается после символа «@», следующего за размером резервирования. Если смещение не указано (или указано нулевым — «0»), то оно будет выбрано автоматически. Пример с указанием размера области резервирования 192 Мб и смещения 32 Мб:

   crashkernel=192M@32M

• Пример задания размера резервируемой памяти в зависимости от объёма оперативной памяти. Используется для предотвращения случаев отказа загрузки системы при уменьшении размера RAM в условиях применяемого параметра crashkernel:

   crashkernel=1G-4G:192M,4G-:256M@32M

  В представленном выше примере будет зарезервировано:

  • 0 Мб (без резервирования) при объеме RAM менее 1 Гб;

  • 192 Мб при объёме RAM от 1 Гб (включительно) до 4 Гб;

  • 256 Мб при объёме RAM от 4 Гб (включительно) и более.

  Задание смещения (@32M) для этого формата не является обязательным (приведено в примере для указания способа его размещения).

Для установки параметра crashkernel воспользуйтесь следующими вариантами:

• Установите стандартное значение параметра crashkernel для текущего ядра командой:

  sudo kdumpctl reset-crashkernel

  Примечание.

  Данный вариант требует установленного пакета grubby и конфигурации меню grub в режиме Boot Loader Specification (BLS).

• Установите нестандартное требуемое значение crashkernel для всех ядер, открыв файл /etc/default/grub и добавив к значению параметра GRUB_CMDLINE_LINUX требуемый  параметр crashkernel=192M@32M:

  GRUB_TIMEOUT=5
  GRUB_DISTRIBUTOR="$(sed 's,\(.*\) release \(.*\)\ .*$,\1 \2,g' /etc/system-release)"
  GRUB_DEFAULT=saved
  GRUB_TERMINAL_OUTPUT="gfxterm"
  GRUB_GFXMODE="1024x768x32"
  GRUB_GFXPAYLOAD_LINUX="1024x768x32"
  GRUB_FONT="/boot/grub2/themes/redos/fixedsys-regular-16.pf2"
  GRUB_CMDLINE_LINUX="resume=/dev/mapper/ro_vbox-swap rd.lvm.lv=ro_vbox/root rd.lvm.lv=ro_vbox/swap rhgb quiet crashkernel=192M@32M"
  GRUB_THEME="/boot/grub2/themes/redos/theme.txt"
  GRUB_ENABLE_BLSCFG=true
  

  После этого обновите меню grub командой:

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

  Примечание.

  Так как резервирование возможно только на этапе загрузки ядра, то для применения изменений параметра crashkernel требуется перезагрузка ОС.

  После перезагрузки ОС проверьте резервирование дампа командой: 

  sudo kdumpctl showmem
  
  kdump: Reserved 192MB memory for crash kernel
  

  Вывод должен указывать на установленный размер резервирования (Reserved 192MB).

Оценка и настройка размера дампа

Для оценки приблизительного размер файла дампа, который будет сгенерирован в случае срабатывания kdump, выполните команду:

sudo makedumpfile --mem-usage /proc/kcore

TYPE		PAGES			EXCLUDABLE	DESCRIPTION
----------------------------------------------------------------------
ZERO		27244           	yes		Pages filled with zero
NON_PRI_CACHE	243569          	yes		Cache pages without private flag
PRI_CACHE	34741           	yes		Cache pages with private flag
USER		148622          	yes		User process pages
FREE		465273          	yes		Free pages
KERN_DATA	91176           	no		Dumpable kernel data 

page size:		4096            
Total pages on system:	1010625         
Total size on system:	4139520000       Byte

В первой колонке вывода команды представлена следующая информация:

• ZERO — страницы памяти, заполненные нулями;

• NON_PRI_CACHE — неприватные страницы кеша;

• PRI_CACHE — приватные страницы кeша;

• USER — страницы данных процессов пользователей;

• FREE — свободные страницы памяти;

• KERN_DATA — доступные для выгрузки данные ядра (всегда включены в состав дампа).
  

Во второй колонке вывода команды указано количество страниц, которые на данный момент используются для каждого типа.

Для расчета размера файла дампа, занимаемого каждым типом, умножьте это значение на размер страницы (стандартный — 4Кб). В примере, представленном выше, страницы данных ядра (KERN_DATA) занимают 364 704 Кб (4 * 91176).

Для настройки параметров создания дампа отредактируйте /etc/kdump.conf. Команда сбора задаётся параметром core_collector.

Пример стандартной настройки:

сore_collector makedumpfile -l --message-level 7 -d 31

Параметр -d команды makedumpfile позволяет указать, какие типы страниц должны быть исключены при сборке дампа. Для получения итогового значения сложите значения страниц, которые выбраны для исключения.

Например, для сохранения только страниц с типом USER, сложите значения исключаемых страниц 1 + 2 + 4 + 16 = 23.

Стандартное значение 31 соответствует сбору в дамп только страниц данных ядра.

Параметр -l команды makedumpfile указывает на использование метода lzo для сжатия страниц дампа.

Допустимые альтернативы параметра -l:

• -c — метод zlib;

• -p — метод snappy; 

• -z — метод zstd.

Параметр --message-level команды makedumpfile позволяет указать типы выводимых сообщений в числовом формате.

Для указания нескольких типов сообщений сложите соответствующие им значения.

По умолчанию включены первые три типа сообщений (значение — 7).

Настройка места сохранения файлов дампа

Для сохранения дампов поддерживаются несколько типов хранилищ (целей), которые настраиваются в файле /etc/kdump.conf.

Одновременное использование нескольких мест сохранения невозможно.

path /<путь_к_каталогу_хранения_дампов>

nfs <NFS-сервер>:/<путь_к_файлам_дампов>

ssh <имя_пользователя>@<SSH-cервер> 
<sshkey> /root/.ssh/kdump-ssh-key
core_collector makedumpfile -F -l --message-level 7 -d 31 

ext4 UUID=25e3e662-c631-4c2c-8ee1-bc8dd9f3f210

raw /dev/vg01/lv-crash 
core_collector makedumpfile -F -l --message-level 7 -d 31

Для всех типов хранилищ (кроме RAW-формата) важное значение имеет параметр path, который задаёт путь сохранения дампов относительно корневого каталога, точки монтирования или точки подключения.

Значение параметра по умолчанию /var/crash/.

Настройка действия по результату создания дампа

Процесс создания файла дампа может завершиться успехом или ошибкой. Для каждого из этих вариантов в /etc/kdump.conf задаётся параметр failure_action, определяющий дальнейшее поведение.

Параметр failure_action определяет действие, вызываемое после успешного создания дампа, а также при возникновении ошибки.

Запуск службы kdump и проверка её статуса

После завершения всех необходимых настроек в /etc/kdump.conf следует активировать службу kdump.

Первый запуск может оказаться длительным из-за процедуры создания образа initramfs.

Пересоберите образ initramfs, если он уже был создан ранее, выполнив команду:

sudo kdumpctl rebuild

Для активации службы выполните команду:

sudo systemctl --now enable kdump

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

sudo systemctl status kdump

● kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
     Active: active (exited) since Wed 2026-01-28 14:56:33 MSK; 16s ago
    Process: 14026 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
   Main PID: 14026 (code=exited, status=0/SUCCESS)
        CPU: 2.215s

янв 28 14:56:31 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming...
янв 28 14:56:33 localhost.localdomain kdumpctl[14029]: kdump: kexec: loaded kdump kernel
янв 28 14:56:33 localhost.localdomain kdumpctl[14029]: kdump: Starting kdump: [OK]
янв 28 14:56:33 localhost.localdomain systemd[1]: Finished Crash recovery kernel arming.

В статусе должно отображаться active (exited).

Проверьте готовность среды kdump: 

sudo kdumpctl status

kdump: Kdump is operational

В статусе должно отображаться is operational.

Если статусы указывают на работоспособное состояние kdump, то можно перейти к тестированию работы механизма.

Тестирование работы kdump

Тестирование механизма kdump осуществляется принудительным вызовом паники ядра через вызов sysrq.

Проверьте статус готовности kdump:

sudo kdumpctl status

kdump: Kdump is operational

Вызовите срабатывание паники ядра:

echo 8 | sudo tee /proc/sys/kernel/sysrq

echo c | sudo tee /proc/sysrq-trigger

В результате должна произойти загрузка в среду kdump, сохранение дампа и перезагрузка системы в обычное состояние (при настройке final_action и failure_action по умолчанию).

Сохранение дампа будет произведено в настроенное хранилище в каталог с именем следующего формата: <IP_адрес>-<ГГГГ-ММ-ДД>-<ЧЧ:ММ:СС>.

Пример состава каталога /var/crash/ с хранилищем в корневой ФС и значением path по умолчанию:

• kexec-dmesg.log — журнал ядра среды kdump, полученный после сохранения дампа;

• vmcore — сжатый файл дампа в формате kdump;

• vmcore-dmesg.txt — журнал ядра основной анализируемой среды, в которой произошёл сбой.

Дамп может быть сохранён с именем vmcore.flat в формате flattern, если в команде makedumpfile был использован параметр -F.

Для преобразования дампа в формат kdump (для анализа инструментом crash) выполните команду:

makedumpfile -R vmcore < vmcore.flat

Утилита kdumpctl

Утилита kdumpctl представляет собой интерфейс для взаимодействия со службой kdump, а также дополнительные функции диагностики и настройки.

Формат вызова:

kdumpctl <команда>

Перечень доступных команд утилиты kdumpctl представлен ниже:

Файл конфигурации kdump.conf

Описание параметров файла конфигурации kdump.conf представлено в таблице:

Проблемы и решения

Паника ядра в среде kdump

Описание:

Среда kdump не загружается. Возникает паника ядра с кодом выхода 0x00007f00 вида:

Kernel panic - not syncing: Attempted to kill init! exitcode=0х00007f00

Решение:

Необходимо увеличить значение параметра crashkernel (см. раздел «Оценка и настройка резервирования памяти для ядра kdump») и перезапустить ОС.

Ошибка «Dump target is invalid»

Описание:

В качестве места хранения дампов выбрана файловая система (раздел). Команды kdumpctl start/restart/rebuild завершаются ошибкой:

kdump: Dump target is invalid

Решение:

1. Проверить правильность указания идентификатора, пути или метки целевого раздела/устройства в /etc/kdump.conf. Скорректировать при необходимости.

2. Добавить точку монтирования для места хранения в /etc/fstab. Автоматическое монтирование необязательно (параметр noauto):

LABEL=crash-dumps /mnt/crdumps/ ext4 defaults,noauto 0 0

3. Повторить сборку initramfs:

sudo kdumpctl rebuild

Ошибка «Dump path ... does not exist in dump target ...»

Описание:

Команды kdumpctl start/restart/rebuild завершаются ошибкой:

kdump: Dump path "</path to-crashes>" does not exist in dump target "LABEL=crash-dumps"

Решение:

В ошибке указано имя каталога, который не обнаружен в сконфигурированном месте хранения. Он определяется параметром path в /etc/kdump.conf. Каталог необходимо создать предварительно до запуска команд (автоматически он не создаётся).

Обратите внимание, что итоговый путь на сервере NFS строится не от корневого каталога, а от каталога NFS-ресурса:

/<каталог_NFS_ресурса>/<значение_path>/

Дата последнего изменения: 10.04.2026

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.