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