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

DEPRECATED OPTIONS

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

EXAMPLES

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

SEE ALSO

333       kexec(8) mkdumprd(8) dracut.cmdline(7)
334
335
336
337kexec-tools                       07/23/2008                     KDUMP.CONF(5)
Impressum