1KDUMP.CONF(5) File Formats Manual KDUMP.CONF(5)
2
6 kdump.conf - configuration file for kdump kernel.
7
10 kdump.conf is a configuration file for the kdump kernel crash collec‐
11 tion service.
12 kdump.conf provides post-kexec instructions to the kdump kernel. It is
14 stored in the initrd file managed by the kdump service. If you change
15 this file and do not want to reboot in order for the changes to take
16 effect, restart the kdump service to rebuild the initrd.
17 For most configurations, you can simply review the examples provided in
19 the stock /etc/kdump.conf.
20 NOTE: For filesystem dumps the dump target must be mounted before
22 building kdump initramfs.
23 kdump.conf only affects the behavior of the initramfs. Please read the
25 kdump operational flow section of kexec-kdump-howto.txt in the docs to
26 better understand how this configuration file affects the behavior of
27 kdump.
28
31 raw <partition>
32 Will dd /proc/vmcore into <partition>. Use persistent device
33 names for partition devices, such as /dev/vg/<devname>.
34 nfs <nfs mount>
36 Will mount nfs to <mnt>, and copy /proc/vmcore to
37 <mnt>/<path>/%HOST-%DATE/, supports DNS. Note that a fqdn should
38 be used as the server name in the mount point.
39 ssh <user@server>
41 Will scp /proc/vmcore to <user@server>:<path>/%HOST-%DATE/, sup‐
42 ports DNS. NOTE: make sure user has necessary write permissions
43 on server and that a fqdn is used as the server name.
44 sshkey <path>
46 Specify the path of the ssh key to use when dumping via ssh.
47 The default value is /root/.ssh/kdump_id_rsa.
48 <fs type> <partition>
50 Will mount -t <fs type> <partition> <mnt>, and copy /proc/vmcore
51 to <mnt>/<path>/%HOST_IP-%DATE/. NOTE: <partition> can be a
52 device node, label or uuid. It's recommended to use persistent
53 device names such as /dev/vg/<devname>. Otherwise it's sug‐
54 gested to use label or uuid.
55 path <path>
57 "path" represents the file system path in which vmcore will be
58 saved. If a dump target is specified in kdump.conf, then "path"
59 is relative to the specified dump target.
60 Interpretation of "path" changes a bit if the user didn't spec‐
62 ify any dump target explicitly in kdump.conf. In this case,
63 "path" represents the absolute path from root. The dump target
64 and adjusted path are arrived at automatically depending on
65 what's mounted in the current system.
66 Ignored for raw device dumps. If unset, will use the default
68 "/var/crash".
69 core_collector <command> <options>
71 This allows you to specify the command to copy the vmcore. The
72 default is makedumpfile, which on some architectures can drasti‐
73 cally reduce core file size. See /sbin/makedumpfile --help for a
74 list of options. Note that the -i and -g options are not needed
75 here, as the initrd will automatically be populated with a con‐
76 fig file appropriate for the running kernel.
77 Note 1: About default core collector: The default core_collector
79 for raw/ssh dump is: "makedumpfile -F -l --message-level 1 -d
80 31". The default core_collector for other targets is: "make‐
81 dumpfile -l --message-level 1 -d 31". Even if core_collector
82 option is commented out in kdump.conf, makedumpfile is the
83 default core collector and kdump uses it internally. If one
84 does not want makedumpfile as default core_collector, then they
85 need to specify one using core_collector option to change the
86 behavior.
87 Note 2: If "makedumpfile -F" is used then you will get a flat‐
89 tened format vmcore.flat, you will need to use "makedumpfile -R"
90 to rearrange the dump data from standard input to a normal dump‐
91 file (readable with analysis tools). ie. "makedumpfile -R
92 vmcore < vmcore.flat"
93 kdump_post <binary | script>
96 This directive allows you to run a specified executable just
97 after the vmcore dump process terminates. The exit status of
98 the current dump process is fed to the kdump_post executable as
99 its first argument($1). Executable can modify it to indicate
100 the new exit status of succeeding dump process,
101 Note that scripts written for use with this directive must use
103 the /bin/bash interpreter.
104 kdump_pre <binary | script>
106 Works just like the "kdump_post" directive, but instead of run‐
107 ning after the dump process, runs immediately before. Exit sta‐
108 tus of this binary is interpreted as follows:
109 0 - continue with dump process as usual
111 non 0 - reboot the system
113 Note that scripts written for this directive must use the
115 /bin/bash interpreter.
116 extra_bins <binaries | shell scripts>
118 This directive allows you to specify additional binaries or
119 shell scripts you'd like to include in your kdump initrd. Gener‐
120 ally only useful in conjunction with a kdump_post binary or
121 script that relies on other binaries or scripts.
122 extra_modules <module(s)>
124 This directive allows you to specify extra kernel modules that
125 you want to be loaded in the kdump initrd, typically used to set
126 up access to non-boot-path dump targets that might otherwise not
127 be accessible in the kdump environment. Multiple modules can be
128 listed, separated by spaces, and any dependent modules will
129 automatically be included.
130 failure_action <reboot | halt | poweroff | shell | dump_to_rootfs>
132 Action to perform in case dumping to the intended target fails.
133 The default is "reboot". reboot: Reboot the system (this is
134 what most people will want, as it returns the system to a normal
135 state). halt: Halt the system and lose the vmcore. poweroff:
136 The system will be powered down. shell: Drop to a shell session
137 inside the initramfs, from which you can manually perform addi‐
138 tional recovery actions. Exiting this shell reboots the system
139 by default or performs "final_action". Note: kdump uses bash as
140 the default shell. dump_to_rootfs: If non-root dump target is
141 specified, the failure action can be set as dump_to_rootfs.
142 That means when dumping to target fails, dump vmcore to rootfs
143 from initramfs context and reboot by default or perform
144 "final_action".
145 default <reboot | halt | poweroff | shell | dump_to_rootfs>
147 Same as the "failure_action" directive above, but this directive
148 is obsolete and will be removed in the future.
149 final_action <reboot | halt | poweroff>
151 Action to perform in case dumping to the intended target suc‐
152 ceeds. Also performed when "shell" or "dump_to_rootfs" failure
153 action finishes. Each action is same as the "failure_action"
154 directive above. The default is "reboot".
155 force_rebuild <0 | 1>
157 By default, kdump initrd will only be rebuilt when necessary.
158 Specify 1 to force rebuilding kdump initrd every time when kdump
159 service starts.
160 force_no_rebuild <0 | 1>
162 By default, kdump initrd will be rebuilt when necessary. Spec‐
163 ify 1 to bypass rebuilding of kdump initrd.
164 force_no_rebuild and force_rebuild options are mutually exclu‐
167 sive and they should not be set to 1 simultaneously.
168 override_resettable <0 | 1>
170 Usually an unresettable block device can't be a dump target.
171 Specifying 1 means that even though the block target is unreset‐
172 table, the user wants to try dumping anyway. By default, it's
173 set to 0, which will not try something destined to fail.
174 dracut_args <arg(s)>
177 Kdump uses dracut to generate initramfs for second kernel. This
178 option allows a user to pass arguments to dracut directly.
179 fence_kdump_args <arg(s)>
182 Command line arguments for fence_kdump_send (it can contain all
183 valid arguments except hosts to send notification to).
184 fence_kdump_nodes <node(s)>
187 List of cluster node(s) except localhost, separated by spaces,
188 to send fence_kdump notification to (this option is mandatory to
189 enable fence_kdump).
190
194 net <nfs mount>|<user@server>
195 net option is replaced by nfs and ssh options. Use nfs or ssh
196 options directly.
197 options <module> <option list>
199 Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump to add mod‐
200 ule options as kernel command line parameters. For example,
201 specify 'loop.max_loop=1' to limit maximum loop devices to 1.
202 link_delay <seconds>
204 link_delay was used to wait for a network device to initialize
205 before using it. Now dracut network module takes care of this
206 issue automatically.
207 disk_timeout <seconds>
209 Similar to link_delay, dracut ensures disks are ready before
210 kdump uses them.
211 debug_mem_level <0-3>
213 Turn on verbose debug output of kdump scripts regarding
214 free/used memory at various points of execution. This feature
215 has been moved to dracut now. Use KDUMP_COMMANDLINE_APPEND in
216 /etc/sysconfig/kdump and append dracut cmdline param rd.memde‐
217 bug=[0-3] to enable the debug output.
218 Higher level means more debugging output.
220 0 - no output
222 1 - partial /proc/meminfo
224 2 - /proc/meminfo
226 3 - /proc/meminfo + /proc/slabinfo
228 blacklist <list of kernel modules>
230 blacklist option was recently being used to prevent loading mod‐
231 ules in initramfs. General terminology for blacklist has been
232 that module is present in initramfs but it is not actually
233 loaded in kernel. Hence retaining blacklist option creates more
234 confusing behavior. It has been deprecated.
235 Instead, use rd.driver.blacklist option on second kernel to
237 blacklist a certain module. One can edit /etc/syscon‐
238 fig/kdump.conf and edit KDUMP_COMMANDLINE_APPEND to pass kernel
239 command line options. Refer to dracut.cmdline man page for more
240 details on module blacklist option.
241
245 Here are some examples for core_collector option:
246 Core collector command format depends on dump target type. Typically
248 for filesystem (local/remote), core_collector should accept two argu‐
249 ments. First one is source file and second one is target file. For ex.
250 ex1. core_collector "cp --sparse=always"
252 Above will effectively be translated to:
254 cp --sparse=always /proc/vmcore <dest-path>/vmcore
256 ex2. core_collector "makedumpfile -l --message-level 1 -d 31"
258 Above will effectively be translated to:
260 makedumpfile -l --message-level 1 -d 31 /proc/vmcore <dest-
262 path>/vmcore
263 For dump targets like raw and ssh, in general, core collector should
265 expect one argument (source file) and should output the processed core
266 on standard output (There is one exception of "scp", discussed later).
267 This standard output will be saved to destination using appropriate
268 commands.
269 raw dumps examples:
271 ex3. core_collector "cat"
273 Above will effectively be translated to.
275 cat /proc/vmcore | dd of=<target-device>
277 ex4. core_collector "makedumpfile -F -l --message-level 1 -d 31"
279 Above will effectively be translated to.
281 makedumpfile -F -l --message-level 1 -d 31 | dd of=<target-
283 device>
284 ssh dumps examples
286 ex5. core_collector "cat"
288 Above will effectively be translated to.
290 cat /proc/vmcore | ssh <options> <remote-location> "dd
292 of=path/vmcore"
293 ex6. core_collector "makedumpfile -F -l --message-level 1 -d 31"
295 Above will effectively be translated to.
297 makedumpfile -F -l --message-level 1 -d 31 | ssh <options>
299 <remote-location> "dd of=path/vmcore"
300 There is one exception to standard output rule for ssh dumps.
302 And that is scp. As scp can handle ssh destinations for file
303 transfers, one can specify "scp" as core collector for ssh tar‐
304 gets (no output on stdout).
305 ex7. core_collector "scp"
307 Above will effectively be translated to.
309 scp /proc/vmcore <user@host>:path/vmcore
311 examples for other options please see /etc/kdump.conf
314
317 kexec(8) mkdumprd(8) dracut.cmdline(7)
318kexec-tools 07/23/2008 KDUMP.CONF(5)