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  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

DEPRECATED OPTIONS

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

EXAMPLES

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

SEE ALSO

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