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 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
45 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
49 <fs type> <partition>
50 Will mount -t <fs type> <partition> <mnt>, and copy /proc/vmcore
51 to <mnt>/<path>/%DATE/. NOTE: <partition> can be a device node,
52 label or uuid. It's recommended to use persistent device names
53 such as /dev/vg/<devname>. Otherwise it's suggested to use
54 label or uuid.
55
56 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
61 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
67 Ignored for raw device dumps. If unset, will use the default
68 "/var/crash".
69
70 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
78 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
88 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
94
95 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
102 Note that scripts written for use with this directive must use
103 the /bin/bash interpreter.
104
105 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
110 0 - continue with dump process as usual
111
112 non 0 - reboot the system
113
114 Note that scripts written for this directive must use the
115 /bin/bash interpreter.
116
117 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
123 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
131 default <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 Note: kdump uses bash as the default shell. dump_to_rootfs: If
140 non-root dump target is specified, the default action can be set
141 as dump_to_rootfs. That means when dumping to target fails,
142 dump vmcore to rootfs from initramfs context and reboot.
143
144 force_rebuild <0 | 1>
145 By default, kdump initrd will only be rebuilt when necessary.
146 Specify 1 to force rebuilding kdump initrd every time when kdump
147 service starts.
148
149 force_no_rebuild <0 | 1>
150 By default, kdump initrd will be rebuilt when necessary. Spec‐
151 ify 1 to bypass rebuilding of kdump initrd.
152
153
154 force_no_rebuild and force_rebuild options are mutually exclu‐
155 sive and they should not be set to 1 simultaneously.
156
157 override_resettable <0 | 1>
158 Usually an unresettable block device can't be a dump target.
159 Specifying 1 means that even though the block target is unreset‐
160 table, the user wants to try dumping anyway. By default, it's
161 set to 0, which will not try something destined to fail.
162
163
164 dracut_args <arg(s)>
165 Kdump uses dracut to generate initramfs for second kernel. This
166 option allows a user to pass arguments to dracut directly.
167
168
169 fence_kdump_args <arg(s)>
170 Command line arguments for fence_kdump_send (it can contain all
171 valid arguments except hosts to send notification to).
172
173
174 fence_kdump_nodes <node(s)>
175 List of cluster node(s) except localhost, separated by spaces,
176 to send fence_kdump notification to (this option is mandatory to
177 enable fence_kdump).
178
179
180
182 net <nfs mount>|<user@server>
183 net option is replaced by nfs and ssh options. Use nfs or ssh
184 options directly.
185
186 options <module> <option list>
187 Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump to add mod‐
188 ule options as kernel command line parameters. For example,
189 specify 'loop.max_loop=1' to limit maximum loop devices to 1.
190
191 link_delay <seconds>
192 link_delay was used to wait for a network device to initialize
193 before using it. Now dracut network module takes care of this
194 issue automatically.
195
196 disk_timeout <seconds>
197 Similar to link_delay, dracut ensures disks are ready before
198 kdump uses them.
199
200 debug_mem_level <0-3>
201 Turn on verbose debug output of kdump scripts regarding
202 free/used memory at various points of execution. This feature
203 has been moved to dracut now. Use KDUMP_COMMANDLINE_APPEND in
204 /etc/sysconfig/kdump and append dracut cmdline param rd.memde‐
205 bug=[0-3] to enable the debug output.
206
207 Higher level means more debugging output.
208
209 0 - no output
210
211 1 - partial /proc/meminfo
212
213 2 - /proc/meminfo
214
215 3 - /proc/meminfo + /proc/slabinfo
216
217 blacklist <list of kernel modules>
218 blacklist option was recently being used to prevent loading mod‐
219 ules in initramfs. General terminology for blacklist has been
220 that module is present in initramfs but it is not actually
221 loaded in kernel. Hence retaining blacklist option creates more
222 confusing behavior. It has been deprecated.
223
224 Instead, use rd.driver.blacklist option on second kernel to
225 blacklist a certain module. One can edit /etc/syscon‐
226 fig/kdump.conf and edit KDUMP_COMMANDLINE_APPEND to pass kernel
227 command line options. Refer to dracut.cmdline man page for more
228 details on module blacklist option.
229
230
231
233 Here are some examples for core_collector option:
234
235 Core collector command format depends on dump target type. Typically
236 for filesystem (local/remote), core_collector should accept two argu‐
237 ments. First one is source file and second one is target file. For ex.
238
239 ex1. core_collector "cp --sparse=always"
240
241 Above will effectively be translated to:
242
243 cp --sparse=always /proc/vmcore <dest-path>/vmcore
244
245 ex2. core_collector "makedumpfile -l --message-level 1 -d 31"
246
247 Above will effectively be translated to:
248
249 makedumpfile -l --message-level 1 -d 31 /proc/vmcore <dest-
250 path>/vmcore
251
252 For dump targets like raw and ssh, in general, core collector should
253 expect one argument (source file) and should output the processed core
254 on standard output (There is one exception of "scp", discussed later).
255 This standard output will be saved to destination using appropriate
256 commands.
257
258 raw dumps examples:
259
260 ex3. core_collector "cat"
261
262 Above will effectively be translated to.
263
264 cat /proc/vmcore | dd of=<target-device>
265
266 ex4. core_collector "makedumpfile -F -l --message-level 1 -d 31"
267
268 Above will effectively be translated to.
269
270 makedumpfile -F -l --message-level 1 -d 31 | dd of=<target-
271 device>
272
273 ssh dumps examples
274
275 ex5. core_collector "cat"
276
277 Above will effectively be translated to.
278
279 cat /proc/vmcore | ssh <options> <remote-location> "dd
280 of=path/vmcore"
281
282 ex6. core_collector "makedumpfile -F -l --message-level 1 -d 31"
283
284 Above will effectively be translated to.
285
286 makedumpfile -F -l --message-level 1 -d 31 | ssh <options>
287 <remote-location> "dd of=path/vmcore"
288
289 There is one exception to standard output rule for ssh dumps.
290 And that is scp. As scp can handle ssh destinations for file
291 transfers, one can specify "scp" as core collector for ssh tar‐
292 gets (no output on stdout).
293
294 ex7. core_collector "scp"
295
296 Above will effectively be translated to.
297
298 scp /proc/vmcore <user@host>:path/vmcore
299
300
301 examples for other options please see /etc/kdump.conf
302
303
305 kexec(8) mkdumprd(8) dracut.cmdline(7)
306
307
308
309kexec-tools 07/23/2008 KDUMP.CONF(5)