LINUX.ORG.RU
решено ФорумAdmin

Прошу помощи с настройкой Kdump на Debian

 , , , ,


0

3

Всем привет. Нужно получить дамп ядра после его паники. Прочитал про Kdump, настроил всё согласно документации. Однако после искусственно вызванной паники ядра - система просто висит. Дамп не собирается, комп после этого не перезагружается. Перепроверял конфиги - не могу понять в чём дело. Прикладываю их:

/etc/default/kdump-tools

# kdump-tools configuration
# ---------------------------------------------------------------------------
# USE_KDUMP - controls kdump will be configured
#     0 - kdump kernel will not be loaded
#     1 - kdump kernel will be loaded and kdump is configured
# KDUMP_SYSCTL - controls when a panic occurs, using the sysctl 
#     interface.  The contents of this variable should be the
#     "variable=value ..." portion of the 'sysctl -w ' command.
#     If not set, the default value "kernel.panic_on_oops=1" will
#     be used.  Disable this feature by setting KDUMP_SYSCTL=" "
#     Example - also panic on oom:
#         KDUMP_SYSCTL="kernel.panic_on_oops=1 vm.panic_on_oom=1"
#
USE_KDUMP=1
#KDUMP_SYSCTL="kernel.panic_on_oops=1"


# ---------------------------------------------------------------------------
# Kdump Kernel:
# KDUMP_KERNEL - A full pathname to a kdump kernel.
# KDUMP_INITRD - A full pathname to the kdump initrd (if used).
#     If these are not set, kdump-config will try to use the current kernel
#     and initrd if it is relocatable.  Otherwise, you will need to specify 
#     these manually.
#KDUMP_KERNEL=/boot/vmlinuz-4.3.0-0.bpo.1-amd64
#KDUMP_INITRD=/boot/initrd.img-4.3.0-0.bpo.1-amd64


# ---------------------------------------------------------------------------
# vmcore Handling:
# KDUMP_COREDIR - local path to save the vmcore to.
# KDUMP_FAIL_CMD - This variable can be used to cause a reboot or
#     start a shell if saving the vmcore fails.  If not set, "reboot -f"
#     is the default.
#     Example - start a shell if the vmcore copy fails:
#         KDUMP_FAIL_CMD="echo 'makedumpfile FAILED.'; /bin/bash; reboot -f"
KDUMP_COREDIR=/var/crash
KDUMP_FAIL_CMD="reboot -f"


# ---------------------------------------------------------------------------
# Makedumpfile options:
# DEBUG_KERNEL - a debug version of the running kernel.  If not set, 
#     kdump-config will use /usr/lib/debug/vmlinux-$(uname -r) if it is
#     available.  If it is not available, makedumpfile will be limited to
#     dumping all pages in memory.
# MAKEDUMP_ARGS - extra arguments passed to makedumpfile (8).  The default,
#     if unset, is to pass '-c -d 31' telling makedumpfile to use compression
#     and reduce the corefile to in-use kernel pages only.
DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-4.5.0-0.bpo.1-amd64
MAKEDUMP_ARGS="-c -d 31"


# ---------------------------------------------------------------------------
# Kexec/Kdump args
# KDUMP_KEXEC_ARGS - Additional arguments to the kexec command used to load
#     the kdump kernel
#     Example - Use this option on x86 systems with PAE and more than
#     4 gig of memory:
#         KDUMP_KEXEC_ARGS="--elf64-core-headers"
# KDUMP_CMDLINE - The default is to use the contents of /proc/cmdline.
#     Set this variable to override /proc/cmdline.
# KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line
#     for the kdump kernel.  If unset, it defaults to "irqpoll maxcpus=1 nousb"
#KDUMP_KEXEC_ARGS=""
#KDUMP_CMDLINE=""
KDUMP_CMDLINE_APPEND="irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service"

# ---------------------------------------------------------------------------
# Architecture specific Overrides:


/etc/default/kexec

# Defaults for kexec initscript
# sourced by /etc/init.d/kexec and /etc/init.d/kexec-load

# Load a kexec kernel (true/false)
LOAD_KEXEC=false

# Kernel and initrd image
KERNEL_IMAGE="/vmlinuz"
INITRD="/initrd.img"

# If empty, use current /proc/cmdline
APPEND=""

# Load the default kernel from grub config (true/false)
USE_GRUB_CONFIG=false


В GRUB прописана опция crashkernel=128M@32M, команда kdump-config status выдаёт current state : ready to kdump Подскажите, в чём причина? Debian 8, ядро 4.5.0

Сколько времени ждал? У меня на rhel6 после паники почему-то происходит таймаут минут 5 до того, как начинается загрузка crash kernel

router ★★★★★ ()
Ответ на: комментарий от alestro
sysctl: permission denied on key 'fs.protected_hardlinks'
sysctl: permission denied on key 'fs.protected_symlinks'
sysctl: permission denied on key 'kernel.cad_pid'
kernel.hardlockup_panic = 0
kernel.hung_task_panic = 0
kernel.panic = 0
kernel.panic_on_io_nmi = 0
kernel.panic_on_oops = 1
kernel.panic_on_unrecovered_nmi = 0
kernel.panic_on_warn = 0
sysctl: kernel.softlockup_panic = 0
permission denied on key 'kernel.usermodehelper.bset'kernel.unknown_nmi_panic = 0

sysctl: permission denied on key 'kernel.usermodehelper.inheritable'
sysctl: permission denied on key 'net.ipv4.tcp_fastopen_key'
sysctl: permission denied on key 'net.ipv6.conf.all.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.br0.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.default.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.docker0.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.eth0.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.eth1.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.lo.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.wwan0.stable_secret'
sysctl: permission denied on key 'vm.mmap_rnd_bits'
sysctl: permission denied on key 'vm.mmap_rnd_compat_bits'
vm.panic_on_oom = 0
Sunderland93 ★★★★★ ()
Ответ на: комментарий от Sunderland93

Тебе надо вот это добавить в /etc/sysctl.conf и сделать sysctl -p

# Enable reboots on panic to allow kdump make dumps
kernel.hung_task_panic = 1
kernel.panic = 1
kernel.panic_on_io_nmi = 1
kernel.panic_on_oops = 1
kernel.panic_on_unrecovered_nmi = 1
kernel.softlockup_panic = 1
kernel.unknown_nmi_panic = 1
vm.panic_on_oom = 1

alestro ()
Ответ на: комментарий от Sunderland93

А панику вызываешь sysrq-c? Если да, то ядро не пробовал другое? У меня на 4.2.0-27 почти такая же конфа для sysrq-c работает.

alestro ()
Ответ на: комментарий от alestro

Да, именно так. Пробовал 4.3, 4.4 и 4.5. Результат одинаковый

Sunderland93 ★★★★★ ()

Проблема решилась обновлением kdump из бэкпортов. Всем спасибо!

Sunderland93 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.