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