KDUMP.CONF(5)KDUMP.CONF(5)NAMEkdump.conf - configuration file for kdump kernel.
DESCRIPTIONkdump.conf is a configuration file for the kdump kernel crash collec‐
tion service.
kdump.conf provides post-kexec instructions to the kdump kernel. It is
stored in the initrd file managed by the kdump service. If you change
this file and do not want to restart before it takes effect, restart
the kdump service to rebuild to initrd.
For most configurations, you can simply review the examples provided in
the stock /etc/kdump.conf.
NOTE: For filesystem dump the dump target must be mounted before build‐
ing kdump initramfs.
kdump.conf only affects the behavior of the initramfs. Please read the
kdump operational flow section of kexec-kdump-howto.txt in the docs to
better understand how this configuration file affects the behavior of
kdump.
OPTIONS
raw <partition>
Will dd /proc/vmcore into <partition>. Use persistent device
names for partition devices, such as /dev/vg/<devname>.
nfs <nfs mount>
Will mount fs and copy /proc/vmcore to
<mnt>/var/crash/%HOST-%DATE/, supports DNS. Note that a fqdn
should be used as the server name in the mount point
ssh <user@server>
Will scp /proc/vmcore to <user@server>:/var/crash/%HOST-%DATE/,
supports DNS. NOTE: make sure user has necessary write permis‐
sions on server and that a fqdn is used as the server name
sshkey <path>
Specifies the path of the ssh key you want to use when do ssh
dump, the default value is /root/.ssh/kdump_id_rsa.
<fs type> <partition>
Will mount -t <fs type> <partition> /mnt and copy /proc/vmcore
to /mnt/var/crash/%DATE/. NOTE: <partition> can be a device
node, label or uuid. It's recommended to use persistent device
names such as /dev/vg/<devname>. Otherwise it's suggested to use
label or uuid.
path <path>
Append path to the filesystem device which you are dumping to.
Ignored for raw device dumps. If unset, will default to
/var/crash.
core_collector <command> <options>
This allows you to specify the command to copy the vmcore. You
could use the dump filtering program makedumpfile, the default
one, to retrieve your core, which on some arches can drastically
reduce core file size. See /sbin/makedumpfile --help for a list
of options. Note that the -i and -g options are not needed
here, as the initrd will automatically be populated with a con‐
fig file appropriate for the running kernel.
Note 1: About default core collector: Default core_collector for
raw/ssh dump is: "makedumpfile -F -c --message-level 1 -d 31".
Default core_collector for other targets is: "makedumpfile -c
--message-level 1 -d 31". Even if core_collector option is com‐
mented out in kdump.conf, makedumpfile is default core collector
and kdump uses it internally. If one does not want makedumpfile
as default core_collector, then they need to specify one using
core_collector option to change the behavior.
Note 2: If "makedumpfile -F" is used then you will get a flat‐
tened format vmcore.flat, you will need to use "makedumpfile -R"
to rearrange the dump data from stdard input to a normal dump‐
file (readable with analysis tools). ie. "makedumpfile -R
vmcore < vmcore.flat"
kdump_post <binary | script>
This directive allows you to run a specified executable just
after the memory dump process terminates. The exit status from
the dump process is fed to the kdump_post executable, which can
be used to trigger different actions for success or failure.
Note that scripts written for use with this directive must use
the /bin/bash interpreter
kdump_pre <binary | script>
Works just like the kdump_post directive, but instead of running
after the dump process, runs immediately before. Exit status of
this binary is interpreted as follows:
0 - continue with dump process as usual
non 0 - reboot the system
Note that scripts written for this directive must use the
/bin/bash interpreter
extra_bins <binaries | shell scripts>
This directive allows you to specify additional binaries or
shell scripts you'd like to include in your kdump initrd. Gener‐
ally only useful in conjunction with a kdump_post binary or
script that relies on other binaries or scripts.
extra_modules <module(s)>
This directive allows you to specify extra kernel modules that
you want to be loaded in the kdump initrd, typically used to set
up access to non-boot-path dump targets that might otherwise not
be accessible in the kdump environment. Multiple modules can be
listed, separated by a space, and any dependent modules will
automatically be included.
default <reboot | halt | poweroff | shell | dump_to_rootfs>
Action to preform in case dumping to intended target fails. If
no default action is specified, "reboot" is assumed default.
reboot: If the default action is reboot simply reboot the system
(this is what most people will want, as it returns the system to
a nominal state). shell: If the default action is shell, then
drop to an shell session inside the initramfs from where you can
manually preform additional recovery actions. Exiting this
shell reboots the system. halt: bring the system to a halt,
requiring manual reset poweroff: The system will be powered
down. dump_to_rootfs:If the default action is dump_to_rootfs,
specified root will be mounted and dump will be saved in "path"
directory. Note: kdump uses bash as the default shell.
force_rebuild <0 | 1>
By default, kdump initrd only will be rebuilt when necessary.
Specify 1 to force rebuilding kdump initrd every time when kdump
service starts.
override_resettable <0 | 1>
Usually a unresettable block device can't be dump target. Speci‐
fying 1 means though block target is unresettable, user under‐
stand this situation and want to try dumping. By default, it's
set to 0, means not to try a destined failure.
dracut_args <arg(s)>
Kdump uses dracut to generate initramfs for second kernel. This
option allows a user to pass arguments to dracut directly.
DEPRECATED OPTIONS
net <nfs mount>|<user@server>
net option is replaced by nfs and ssh options. Use nfs or ssh
options directly.
options <module> <option list>
Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump to add
proper module option as kernel command line params. Such as
append loop.max_loop=1 to limit maximum loop devices to 1.
link_delay <seconds>
link_delay was used to wait a network device to initialize
before using it. Now dracut network module take care of this
issue automaticlly.
disk_timeout <seconds>
Similar to link_delay, dracut ensures disks being ready before
kdump uses them.
debug_mem_level <0-3>
This was used to turns on debug/verbose output of kdump scripts
regarding free/used memory at various points of execution. This
feature has been moved to dracut now. Use KDUMP_COMMAND‐
LINE_APPEND in /etc/sysconfig/kdump and append dracut cmdline
param rd.memdebug=[0-3] to enable the debug output.
Higher level means more debugging output.
0 - no output
1 - partial /proc/meminfo
2 - /proc/meminfo
3 - /proc/meminfo + /proc/slabinfo
blacklist <list of kernel modules>
blacklist option was recently being used to prevent loading mod‐
ules in initramfs. General terminology for blacklist has been
that module is present in initramfs but it is not actually
loaded in kernel. Hence retaining blacklist option creates more
confusing behavior. It has been deprecated.
Instead use rd.driver.blacklist option on second kernel to
blacklist a certain module. One can edit /etc/syscon‐
fig/kdump.conf and edit KDUMP_COMMANDLINE_APPEND to pass kernel
command line options. Refer to dracut.cmdline man page for more
details on module blacklist option.
EXAMPLES
Here is some examples for core_collector option:
Core collector command format depends on dump target type. Typically
for filesystem (local/remote), core_collector should accept two argu‐
ments. First one is source file and second one is target file. For ex.
ex1. core_collector "cp --sparse=always"
Above will effectively be translated to:
cp --sparse=always /proc/vmcore <dest-path>/vmcore
ex2. core_collector "makedumpfile -c --message-level 1 -d 31"
Above will effectively be translated to:
makedumpfile -c --message-level 1 -d 31 /proc/vmcore <dest-
path>/vmcore
For dump targets like raw and ssh, in general, core collector should
expect one argument (source file) and should output the processed core
on standard output (There is one exception of "scp", discussed later).
This standard output will be saved to destination using appropriate
commands.
raw dumps examples:
ex3. core_collector "cat"
Above will effectively be translated to.
cat /proc/vmcore | dd of=<target-device>
ex4. core_collector "makedumpfile -F -c --message-level 1 -d 31"
Above will effectively be translated to.
makedumpfile -F -c --message-level 1 -d 31 | dd of=<target-
device>
ssh dumps examples
ex5. core_collector "cat"
Above will effectively be translated to.
cat /proc/vmcore | ssh <options> <remote-location> "dd
of=path/vmcore"
ex6. core_collector "makedumpfile -F -c --message-level 1 -d 31"
Above will effectively be translated to.
makedumpfile -F -c --message-level 1 -d 31 | ssh <options>
<remote-location> "dd of=path/vmcore"
There is one exception to standard output rule for ssh dumps.
And that is scp. As scp can handle ssh destinations for file
transfers, one can specify "scp" as core collector for ssh tar‐
gets (no output on stdout).
ex7. core_collector "scp"
Above will effectively be translated to.
scp /proc/vmcore <user@host>:path/vmcore
examples for other options please see /etc/kdump.conf
SEE ALSOkexec(8)mkdumprd(8)dracut.cmdline(7)kexec-tools 07/23/2008 KDUMP.CONF(5)
