|
Bog BOS: kdump |
Последние изменения: |
Последнее изменение файла: 2017.10.20
Скопировано с www.bog.pp.ru: 2024.11.11
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)
Основные возможности
|
Bog BOS: kdump |
Последние изменения: |