1KDUMP.CONF(5)                 File Formats Manual                KDUMP.CONF(5)
2
3
4

NAME

6       kdump.conf - configuration file for kdump kernel.
7
8

DESCRIPTION

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

OPTIONS

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

DEPRECATED OPTIONS

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

EXAMPLES

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

SEE ALSO

362       kexec(8) mkdumprd(8) dracut.cmdline(7)
363
364
365
366kexec-tools                       07/23/2008                     KDUMP.CONF(5)
Impressum