@ Карта сайта News Автора!

Bog BOS: kdump

Последние изменения:
2017.10.24: hard: Таблицы разделов MBR и GPT

Последнее изменение файла: 2017.10.20
Скопировано с www.bog.pp.ru: 2017.11.18

Bog BOS: kdump

kdump позволяет при аварийном завершении работы ядра сохранить содержимое памяти (/proc/vmcore) и dmesg для последующего анализа.

Архитектура

Использует

Инициируется в случае паники ядра, нажатию Alt-SysRq C, сторожа NMI (NMI_WATCHDOG, необходимо позаботиться, чтобы необходимый модуль загружался в новое ядро, иначе сторож сбросит и его), при включённой панике (/proc/sys/kernel/panic_on_oops), нажатию клавиши NMI (/proc/sys/kernel/unknown_nmi_panic), см. также /proc/sys/kernel/panic_on_warn.

Установка

При установке kdump можно включить ключом inst.kdump_addon=on (по умолчанию?!) или в kickstart (начиная с RHEL 7.1). Установить вручную можно с помощью пакета kexec-tool (графический интерфейс в пакете system-config-kdump). Не рекомендуется Intel IOMMU до RHEL 7.4 (?!).

Запустить сервис kdump

Проверить готовность можно в /sys/kernel/kexec_crash_loaded.

Настройка

Для работы второго ядра резервируется часть оперативной памяти - для архитектуры x86_64 резервируется 160 MB и по 2 бита на каждую страницу памяти (страница - 4 КиБ), т.е. 224 МБ для сервера с 1 ТиБ ОП, размер задаётся опцией загрузки ядра

crashkernel={auto|размер[@смещение]}

При тестировании (CentOS 7.4) оказалось что автоматически памяти выделяется маловато:

CentOS 6.9
Found 137MB of memory at 48MB for crashkernel auto 
Reserving 137MB of memory at 48MB for crashkernel (System RAM: 132096MB)
crash memory driver: version 1.1

CentOS7.4
Reserving 164MB of memory at 656MB for crashkernel (System RAM: 65500MB)

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

Out of memory: Kill process systemd-udevd
     и дальше всё плохо

Поменял в /etc/default/grub "crashkernel=auto" на "crashkernel=224M" и пересобрал grub.cfg: "grub2-mkconfig -o /boot/grub2/grub.cfg"

Reserving 224MB of memory at 608MB for crashkernel (System RAM: 65500MB)
crash memory driver: version 1.1

Настройки (/etc/kdump.conf, kdump.conf(5), только 1 направление складирования (рекомендуется раздел или выделенная файловая система), раздел можно указывать в виде явного указания или LABEL=метка или UUID=идентификатор, файловые системы должны быть описаны в /etc/fstab, после изменения необходимо смонтировать файловую систему и перезапустить сервис kdump - перезаписывает в initrd):

Настройка видео не поддерживается. Можно попробовать добавить ключ "--reset-vga" в командную строку запуска kdump (KDUMP_COMMANDLINE в /etc/sysconfig/kdump) или добавить модуль vga15fb.ko в extra_modules.

Встроенный в initrd для kdump dracut требует монтирования корневой файловой системы, что может вызвать проблемы после сбоя. Можно подсунуть ему что-то безопасное.

Параметры утилиты сжатия makedumpfile (makedumpfile.conf(5), сжимает /proc/vmcore и фильтрует ненужное в формате kdump-compressed для утилиты crash или ELF для gdb и crash)

Пробный крах

Опробовал в CentOS 7.4 на примере NFS (писать в локальную файловую систему после краха ядра - плохая мысль; можно выделить специальный логический том с ext4, но не везде есть место; ещё лучше ssh с выделенным пользователем)

при загрузке crashkernel=224M

/etc/kdump.conf:
nfs сервер:/точка-монтирования
path kdump # создана заранее 777t, осторожно - чувствительная информация
core_collector makedumpfile -l --message-level 7 -d 31
default reboot

systemctl restart kdump
systemctl is-active kdump # /sys/kernel/kexec_crash_loaded

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

на NFS сервере в каталоге kdump появился каталог 192.168.175.136-2017-10-19-18:45:20 с файлами vmcore (менее 1ГБ) и vmcore-dmesg.txt

Анализ

Для анализа необходимы пакеты kernel-debuginfo и kernel-debuginfo-common то же самой версии (2 ГБ, для создания обычного дампа не требуются).

Запуск crash (пакет crash, crash.8):

crash /usr/lib/debug/lib/modules/.../vmlinux  .../vmcore

      KERNEL: /usr/lib/debug/lib/modules/3.10.0-693.2.2.el7.x86_64/vmlinux
    DUMPFILE: /share4s/kdump/192.168.175.136-2017-10-19-19:52:27/vmcore  [PARTIAL DUMP]
        CPUS: 8
        DATE: Thu Oct 19 19:52:05 2017
      UPTIME: 00:02:22
LOAD AVERAGE: 0.49, 0.48, 0.21
       TASKS: 383
    NODENAME: x136.cs.niisi.ras.ru
     RELEASE: 3.10.0-693.2.2.el7.x86_64
     VERSION: #1 SMP Tue Sep 12 22:26:13 UTC 2017
     MACHINE: x86_64  (3500 Mhz)
      MEMORY: 64 GB
       PANIC: "SysRq : Trigger a crash"
         PID: 3417
     COMMAND: "bash"
        TASK: ffff88084cfaaf70  [THREAD_INFO: ffff88084da94000]
         CPU: 7
       STATE: TASK_RUNNING (SYSRQ)

Основные возможности

Ссылки

@ Карта сайта News Автора!

Bog BOS: kdump

Последние изменения:
2017.10.24: hard: Таблицы разделов MBR и GPT

TopList

Copyright © 1996-2017 Sergey E. Bogomolov; www.bog.pp.ru (КГБ знает все, даже то что у Вас на диске ;)