kdump.conf(5) - phpMan

KDUMP.CONF(5) File Formats Manual KDUMP.CONF(5)

NAME
kdump.conf - configuration file for kdump kernel.

DESCRIPTION
kdump.conf is a configuration file for the kdump kernel crash collection service.

kdump.conf provides post-kexec instructions to the kdump kernel. It is stored in the ini-
trd file managed by the kdump service. If you change this file and do not want to reboot
in order for the changes to take effect, restart the kdump service to rebuild the initrd.

For most configurations, you can simply review the examples provided in the stock
/etc/kdump.conf.

NOTE: For filesystem dumps the dump target must be mounted before building 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 configura-
tion 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 nfs to <mnt>, and copy /proc/vmcore to <mnt>/<path>/%HOST-%DATE/, sup-
ports 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>:<path>/%HOST-%DATE/, supports DNS. NOTE:
make sure user has necessary write permissions on server and that a fqdn is used as
the server name.

sshkey <path>
Specify the path of the ssh key to use when dumping via ssh. 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>/<path>/%HOST_IP-%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>
"path" represents the file system path in which vmcore will be saved. If a dump
target is specified in kdump.conf, then "path" is relative to the specified dump
target.

Interpretation of "path" changes a bit if the user didn't specify any dump target
explicitly in kdump.conf. In this case, "path" represents the absolute path from
root. The dump target and adjusted path are arrived at automatically depending on
what's mounted in the current system.

Ignored for raw device dumps. If unset, will use the default "/var/crash".

core_collector <command> <options>
This allows you to specify the command to copy the vmcore. The default is make-
dumpfile, which on some architectures 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 config
file appropriate for the running kernel.

Note 1: About default core collector: The default core_collector for raw/ssh dump
is: "makedumpfile -F -l --message-level 1 -d 31". The default core_collector for
other targets is: "makedumpfile -l --message-level 1 -d 31". Even if core_collec-
tor option is commented out in kdump.conf, makedumpfile is the default core collec-
tor 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 flattened format
vmcore.flat, you will need to use "makedumpfile -R" to rearrange the dump data from
standard input to a normal dumpfile (readable with analysis tools). ie. "makedump-
file -R vmcore < vmcore.flat"

kdump_post <binary | script>
This directive allows you to run a specified executable just after the vmcore dump
process terminates. The exit status of the current dump process is fed to the
kdump_post executable as its first argument($1). Executable can modify it to indi-
cate the new exit status of succeeding dump process,

Note that scripts written for use with this directive must use the /bin/bash inter-
preter.

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. Generally 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 spaces, and any dependent modules will automat-
ically be included.

default <reboot | halt | poweroff | shell | dump_to_rootfs>
Action to perform in case dumping to the intended target fails. The default is
"reboot". reboot: Reboot the system (this is what most people will want, as it
returns the system to a normal state). halt: Halt the system and lose the vmcore.
poweroff: The system will be powered down. shell: Drop to a shell session inside
the initramfs, from which you can manually perform additional recovery actions.
Exiting this shell reboots the system. Note: kdump uses bash as the default shell.
dump_to_rootfs: If non-root dump target is specified, the default action can be set
as dump_to_rootfs. That means when dumping to target fails, dump vmcore to rootfs
from initramfs context and reboot.

force_rebuild <0 | 1>
By default, kdump initrd will only be rebuilt when necessary. Specify 1 to force
rebuilding kdump initrd every time when kdump service starts.

force_no_rebuild <0 | 1>
By default, kdump initrd will be rebuilt when necessary. Specify 1 to bypass
rebuilding of kdump initrd.

force_no_rebuild and force_rebuild options are mutually exclusive and they should
not be set to 1 simultaneously.

override_resettable <0 | 1>
Usually an unresettable block device can't be a dump target. Specifying 1 means
that even though the block target is unresettable, the user wants to try dumping
anyway. By default, it's set to 0, which will not try something destined to fail.

dracut_args <arg(s)>
Kdump uses dracut to generate initramfs for second kernel. This option allows a
user to pass arguments to dracut directly.

fence_kdump_args <arg(s)>
Command line arguments for fence_kdump_send (it can contain all valid arguments
except hosts to send notification to).

fence_kdump_nodes <node(s)>
List of cluster node(s) except localhost, separated by spaces, to send fence_kdump
notification to (this option is mandatory to enable fence_kdump).

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 module options as ker-
nel command line parameters. For example, specify 'loop.max_loop=1' to limit maxi-
mum loop devices to 1.

link_delay <seconds>
link_delay was used to wait for a network device to initialize before using it.
Now dracut network module takes care of this issue automatically.

disk_timeout <seconds>
Similar to link_delay, dracut ensures disks are ready before kdump uses them.

debug_mem_level <0-3>
Turn on verbose debug output of kdump scripts regarding free/used memory at various
points of execution. This feature has been moved to dracut now. Use KDUMP_COMMAN-
DLINE_APPEND in /etc/sysconfig/kdump and append dracut cmdline param rd.memde-
bug=[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 modules 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/sysconfig/kdump 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 are 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 arguments. 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 -l --message-level 1 -d 31"

Above will effectively be translated to:

makedumpfile -l --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 excep-
tion of "scp", discussed later). This standard output will be saved to destination using
appropriate commands.

raw dumps examples:

ex3. core_collector "cat"