1KDUMP.CONF(5) File Formats Manual KDUMP.CONF(5)
2
3
4
6 kdump.conf - configuration file for kdump kernel.
7
8
10 kdump.conf is a configuration file for the kdump kernel crash collec‐
11 tion service.
12
13 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
18 For most configurations, you can simply review the examples provided in
19 the stock /etc/kdump.conf.
20
21 NOTE: For filesystem dumps the dump target must be mounted before
22 building kdump initramfs.
23
24 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
29
31 auto_reset_crashkernel <yes|no>
32 determine whether to reset kernel crashkernel to new default
33 value or not when kexec-tools updates the default crashkernel
34 value and existing kernels using the old default kernel crashk‐
35 ernel value
36
37 raw <partition>
38 Will dd /proc/vmcore into <partition>. Use persistent
39 device names for partition devices, such as /dev/vg/<dev‐
40 name>.
41
42 nfs <nfs mount>
43 Will mount nfs to <mnt>, and copy /proc/vmcore to
44 <mnt>/<path>/%HOST-%DATE/, supports DNS. Note that a fqdn
45 should be used as the server name in the mount point.
46
47 ssh <user@server>
48 Will save /proc/vmcore through ssh pipe to
49 <user@server>:<path>/%HOST-%DATE/, supports DNS. NOTE:
50 make sure user has necessary write permissions on server
51 and that a fqdn is used as the server name.
52
53 sshkey <path>
54 Specify the path of the ssh key to use when dumping via
55 ssh. The default value is /root/.ssh/kdump_id_rsa.
56
57 <fs type> <partition>
58 Will mount -t <fs type> <partition> <mnt>, and copy
59 /proc/vmcore to <mnt>/<path>/%HOST_IP-%DATE/. NOTE:
60 <partition> can be a device node, label or uuid. It's
61 recommended to use persistent device names such as
62 /dev/vg/<devname>. Otherwise it's suggested to use label
63 or uuid.
64
65 path <path>
66 "path" represents the file system path in which vmcore
67 will be saved. If a dump target is specified in
68 kdump.conf, then "path" is relative to the specified dump
69 target.
70
71 Interpretation of "path" changes a bit if the user didn't
72 specify any dump target explicitly in kdump.conf. In this
73 case, "path" represents the absolute path from root. The
74 dump target and adjusted path are arrived at automati‐
75 cally depending on what's mounted in the current system.
76
77 Ignored for raw device dumps. If unset, will use the de‐
78 fault "/var/crash".
79
80 core_collector <command> <options>
81 This allows you to specify the command to copy the vm‐
82 core. The default is makedumpfile, which on some archi‐
83 tectures can drastically reduce core file size. See
84 /sbin/makedumpfile --help for a list of options. Note
85 that the -i and -g options are not needed here, as the
86 initrd will automatically be populated with a config file
87 appropriate for the running kernel.
88
89 Note 1: About default core collector: The default
90 core_collector for raw/ssh dump is: "makedumpfile -F -l
91 --message-level 7 -d 31". The default core_collector for
92 other targets is: "makedumpfile -l --message-level 7 -d
93 31". Even if core_collector option is commented out in
94 kdump.conf, makedumpfile is the default core collector
95 and kdump uses it internally. If one does not want make‐
96 dumpfile as default core_collector, then they need to
97 specify one using core_collector option to change the be‐
98 havior.
99
100 Note 2: If "makedumpfile -F" is used then you will get a
101 flattened format vmcore.flat, you will need to use "make‐
102 dumpfile -R" to rearrange the dump data from standard in‐
103 put to a normal dumpfile (readable with analysis tools).
104 ie. "makedumpfile -R vmcore < vmcore.flat"
105
106 Note 3: If specified core_collector simply copy the vm‐
107 core file to the dump target (eg: cp, scp), the vmcore
108 could be significantly large. Please make sure the dump
109 target has enough space, at leaset larger than the sys‐
110 tem's RAM.
111
112
113 kdump_post <binary | script>
114 This directive allows you to run a specified executable
115 just after the vmcore dump process terminates. The exit
116 status of the current dump process is fed to the
117 kdump_post executable as its first argument($1). Exe‐
118 cutable can modify it to indicate the new exit status of
119 succeeding dump process,
120
121 All files under /etc/kdump/post.d are collectively sorted
122 and executed in lexical order, before binary or script
123 specified kdump_post parameter is executed.
124
125 Note that scripts written for use with this directive
126 must use the /bin/bash interpreter. And since these
127 scripts run in kdump enviroment, the reference to the
128 storage or network device in the scripts should adhere to
129 the section
130
131
132 kdump_pre <binary | script>
133 Works just like the "kdump_post" directive, but instead
134 of running after the dump process, runs immediately be‐
135 fore. Exit status of this binary is interpreted as fol‐
136 lows:
137
138 0 - continue with dump process as usual
139
140 non 0 - run the final action (reboot/poweroff/halt)
141
142 All files under /etc/kdump/pre.d are collectively sorted
143 and executed in lexical order, after binary or script
144 specified kdump_pre parameter is executed. Even if the
145 binary or script in /etc/kdump/pre.d directory returns
146 non 0 exit status, the processing is continued.
147
148 Note that scripts written for use with this directive
149 must use the /bin/bash interpreter. And since these
150 scripts run in kdump enviroment, the reference to the
151 storage or network device in the scripts should adhere to
152 the section
153
154
155 extra_bins <binaries | shell scripts>
156 This directive allows you to specify additional binaries
157 or shell scripts you'd like to include in your kdump ini‐
158 trd. Generally only useful in conjunction with a
159 kdump_post binary or script that relies on other binaries
160 or scripts.
161
162 extra_modules <module(s)>
163 This directive allows you to specify extra kernel modules
164 that you want to be loaded in the kdump initrd, typically
165 used to set up access to non-boot-path dump targets that
166 might otherwise not be accessible in the kdump environ‐
167 ment. Multiple modules can be listed, separated by spa‐
168 ces, and any dependent modules will automatically be in‐
169 cluded.
170
171 failure_action <reboot | halt | poweroff | shell |
172 dump_to_rootfs>
173 Action to perform in case dumping to the intended target
174 fails. The default is "reboot". reboot: Reboot the sys‐
175 tem (this is what most people will want, as it returns
176 the system to a normal state). halt: Halt the system and
177 lose the vmcore. poweroff: The system will be powered
178 down. shell: Drop to a shell session inside the
179 initramfs, from which you can manually perform additional
180 recovery actions. Exiting this shell reboots the system
181 by default or performs "final_action". Note: kdump uses
182 bash as the default shell. dump_to_rootfs: If non-root
183 dump target is specified, the failure action can be set
184 as dump_to_rootfs. That means when dumping to target
185 fails, dump vmcore to rootfs from initramfs context and
186 reboot by default or perform "final_action".
187
188 default <reboot | halt | poweroff | shell | dump_to_rootfs>
189 Same as the "failure_action" directive above, but this
190 directive is obsolete and will be removed in the future.
191
192 final_action <reboot | halt | poweroff>
193 Action to perform in case dumping to the intended target
194 succeeds. Also performed when "shell" or
195 "dump_to_rootfs" failure action finishes. Each action is
196 same as the "failure_action" directive above. The de‐
197 fault is "reboot".
198
199 force_rebuild <0 | 1>
200 By default, kdump initrd will only be rebuilt when neces‐
201 sary. Specify 1 to force rebuilding kdump initrd every
202 time when kdump service starts.
203
204 force_no_rebuild <0 | 1>
205 By default, kdump initrd will be rebuilt when necessary.
206 Specify 1 to bypass rebuilding of kdump initrd.
207
208
209 force_no_rebuild and force_rebuild options are mutually
210 exclusive and they should not be set to 1 simultaneously.
211
212 override_resettable <0 | 1>
213 Usually an unresettable block device can't be a dump tar‐
214 get. Specifying 1 means that even though the block target
215 is unresettable, the user wants to try dumping anyway.
216 By default, it's set to 0, which will not try something
217 destined to fail.
218
219
220 dracut_args <arg(s)>
221 Kdump uses dracut to generate initramfs for second ker‐
222 nel. This option allows a user to pass arguments to dra‐
223 cut directly.
224
225
226 fence_kdump_args <arg(s)>
227 Command line arguments for fence_kdump_send (it can con‐
228 tain all valid arguments except hosts to send notifica‐
229 tion to).
230
231
232 fence_kdump_nodes <node(s)>
233 List of cluster node(s) except localhost, separated by
234 spaces, to send fence_kdump notification to (this option
235 is mandatory to enable fence_kdump).
236
237
238
240 net <nfs mount>|<user@server>
241 net option is replaced by nfs and ssh options. Use nfs or ssh
242 options directly.
243
244 options <module> <option list>
245 Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump to add mod‐
246 ule options as kernel command line parameters. For example,
247 specify 'loop.max_loop=1' to limit maximum loop devices to 1.
248
249 link_delay <seconds>
250 link_delay was used to wait for a network device to initialize
251 before using it. Now dracut network module takes care of this
252 issue automatically.
253
254 disk_timeout <seconds>
255 Similar to link_delay, dracut ensures disks are ready before
256 kdump uses them.
257
258 debug_mem_level <0-3>
259 Turn on verbose debug output of kdump scripts regarding
260 free/used memory at various points of execution. This feature
261 has been moved to dracut now. Use KDUMP_COMMANDLINE_APPEND in
262 /etc/sysconfig/kdump and append dracut cmdline param rd.memde‐
263 bug=[0-3] to enable the debug output.
264
265 Higher level means more debugging output.
266
267 0 - no output
268
269 1 - partial /proc/meminfo
270
271 2 - /proc/meminfo
272
273 3 - /proc/meminfo + /proc/slabinfo
274
275 blacklist <list of kernel modules>
276 blacklist option was recently being used to prevent loading mod‐
277 ules in initramfs. General terminology for blacklist has been
278 that module is present in initramfs but it is not actually
279 loaded in kernel. Hence retaining blacklist option creates more
280 confusing behavior. It has been deprecated.
281
282 Instead, use rd.driver.blacklist option on second kernel to
283 blacklist a certain module. One can edit /etc/syscon‐
284 fig/kdump.conf and edit KDUMP_COMMANDLINE_APPEND to pass kernel
285 command line options. Refer to dracut.cmdline man page for more
286 details on module blacklist option.
287
288
289
291 Here are some examples for core_collector option:
292
293 Core collector command format depends on dump target type. Typically
294 for filesystem (local/remote), core_collector should accept two argu‐
295 ments. First one is source file and second one is target file. For ex.
296
297 ex1. core_collector "cp --sparse=always"
298
299 Above will effectively be translated to:
300
301 cp --sparse=always /proc/vmcore <dest-path>/vmcore
302
303 ex2. core_collector "makedumpfile -l --message-level 7 -d 31"
304
305 Above will effectively be translated to:
306
307 makedumpfile -l --message-level 7 -d 31 /proc/vmcore <dest-
308 path>/vmcore
309
310 For dump targets like raw and ssh, in general, core collector should
311 expect one argument (source file) and should output the processed core
312 on standard output (There is one exception of "scp", discussed later).
313 This standard output will be saved to destination using appropriate
314 commands.
315
316 raw dumps examples:
317
318 ex3. core_collector "cat"
319
320 Above will effectively be translated to.
321
322 cat /proc/vmcore | dd of=<target-device>
323
324 ex4. core_collector "makedumpfile -F -l --message-level 7 -d 31"
325
326 Above will effectively be translated to.
327
328 makedumpfile -F -l --message-level 7 -d 31 | dd of=<target-de‐
329 vice>
330
331 ssh dumps examples
332
333 ex5. core_collector "cat"
334
335 Above will effectively be translated to.
336
337 cat /proc/vmcore | ssh <options> <remote-location> "dd
338 of=path/vmcore"
339
340 ex6. core_collector "makedumpfile -F -l --message-level 7 -d 31"
341
342 Above will effectively be translated to.
343
344 makedumpfile -F -l --message-level 7 -d 31 | ssh <options> <re‐
345 mote-location> "dd of=path/vmcore"
346
347 There is one exception to standard output rule for ssh dumps.
348 And that is scp. As scp can handle ssh destinations for file
349 transfers, one can specify "scp" as core collector for ssh tar‐
350 gets (no output on stdout).
351
352 ex7. core_collector "scp"
353
354 Above will effectively be translated to.
355
356 scp /proc/vmcore <user@host>:path/vmcore
357
358
359 examples for other options please see /etc/kdump.conf
360
361
363 kexec(8) mkdumprd(8) dracut.cmdline(7)
364
365
366
367kexec-tools 07/23/2008 KDUMP.CONF(5)