This was formerly done by Freeman, now I take it over with a few further fixes.
Xunlei Pang (2): kdump.conf comments fixes kdump.conf man page fixes
kdump.conf | 193 +++++++++++++++++++++++++++++++---------------------------- kdump.conf.5 | 113 +++++++++++++++++----------------- 2 files changed, 154 insertions(+), 152 deletions(-)
The default action comment about "halt" is wrong, default action means the action to perform after a vmcore saving failure.
Also there are lots of typos and incorrect expressions. Fix them here as well.
Reported-by: Donald Berry dberry@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com --- kdump.conf | 193 ++++++++++++++++++++++++++++++++----------------------------- 1 file changed, 100 insertions(+), 93 deletions(-)
diff --git a/kdump.conf b/kdump.conf index 54b581d..6c4d372 100644 --- a/kdump.conf +++ b/kdump.conf @@ -1,80 +1,90 @@ -# Configures where to put the kdump /proc/vmcore files -# -# This file contains a series of commands to perform (in order) when a -# kernel crash has happened and the kdump kernel has been loaded. Directives in -# this file are only applicable to the kdump initramfs, and have no effect if -# the root filesystem is mounted and the normal init scripts are processed -# -# Currently only one dump target and path may be configured at once -# if the configured dump target fails, the default action will be preformed -# the default action may be configured with the default directive below. If the -# configured dump target succedes -# -# Basics commands supported are: -# raw <partition> - Will dd /proc/vmcore into <partition>. -# Use persistent device names for partition devices, -# such as /dev/vg/<devname>. -# -# nfs <nfs mount> - Will mount fs and copy /proc/vmcore to -# <mnt>/var/crash/%HOST-%DATE/, supports DNS. -# -# ssh user@server - Will scp /proc/vmcore to -# user@server:/var/crash/%HOST-%DATE/, supports DNS -# NOTE: make sure user has necessary write -# permissions on server -# -# sshkey <path> - Will use the sshkey to do ssh dump -# Specifies the path of the ssh key you want to use -# when do ssh dump, the default value is -# /root/.ssh/kdump_id_rsa. -# -# <fs type> <partition> - Will mount -t <fs type> <partition> /mnt and copy -# /proc/vmcore to /mnt/var/crash/%DATE/. +# This file contains a series of commands to perform (in order) in the kdump +# kernel after a kernel crash in the crash kernel(1st kernel) has happened. +# +# Directives in this file are only applicable to the kdump initramfs, and have +# no effect once the root filesystem is mounted and the normal init scripts are +# processed. +# +# Currently, only one dump target and path can be specified. If the dumping to +# the configured target fails, the default action which can be configured via the +# "default" directive will be performed. +# +# Supported options: +# +# raw <partition> +# - Will dd /proc/vmcore into <partition>. +# Use persistent device names for partition devices, such as +# /dev/vg/<devname>. +# +# nfs <nfs mount> +# - Will mount nfs to <mnt>, and copy /proc/vmcore to +# <mnt>/<path>/%HOST-%DATE/, supports DNS. +# +# ssh user@server +# - Will scp /proc/vmcore to user@server:<path>/%HOST-%DATE/, +# supports DNS. +# NOTE: make sure the user has necessary write permissions on +# the server. +# +# sshkey <path> +# - Will use the sshkey to do ssh dump. +# Specify the path of the ssh key to use when dumping via ssh. +# The default value is /root/.ssh/kdump_id_rsa. +# +# <fs type> <partition> +# - Will mount -t <fs type> <partition> <mnt>, and copy +# /proc/vmcore to <mnt>/<path>/%DATE/. # NOTE: <partition> can be a device node, label or uuid. # It's recommended to use persistent device names # such as /dev/vg/<devname>. # Otherwise it's suggested to use label or uuid. # -# path <path> - "path" represents the file system path in which -# vmcore will be saved. If a dump target is specified -# in kdump.conf, then "path" is relative to the -# specified dump target. Interpretation of path -# changes a bit if user has not specified a dump -# target explicitly in kdump.conf. In this case, -# "path" represents the absolute path from root. -# And dump target and adjusted path are arrived -# at automatically depending on what's mounted -# in the current system. -# Ignored for raw device dumps. If unset, will -# default to /var/crash. +# path <path> +# - "path" represents the file system path in which vmcore +# will be saved. If a dump target is specified in +# kdump.conf, then "path" is relative to the specified +# dump target. +# +# Interpretation of "path" changes a bit if the user didn't +# specify any dump target explicitly in kdump.conf. In this +# case, "path" represents the absolute path from root. The +# dump target and adjusted path are arrived at automatically +# depending on what's mounted in the current system. +# +# Ignored for raw device dumps. If unset, will use the default +# "/var/crash". # # core_collector <command> <options> # - This allows you to specify the command to copy -# the vmcore. You could use the dump filtering -# program makedumpfile, the default one, to retrieve -# your core, which on some arches can drastically -# reduce core file size. See /sbin/makedumpfile --help -# for a list of options. Note that the -i and -g -# options are not needed here, as the initrd will -# automatically be populated with a config file -# appropriate for the running kernel. -# Default core_collector for raw/ssh dump is: +# the vmcore. The default is makedumpfile, which on +# some architectures can drastically reduce core file size. +# See /sbin/makedumpfile --help for a list of options. +# Note that the -i and -g options are not needed here, +# as the initrd will automatically be populated with a +# config file appropriate for the running kernel. +# The default core_collector for raw/ssh dump is: # "makedumpfile -F -l --message-level 1 -d 31". -# Default core_collector for other targets is: +# The default core_collector for other targets is: # "makedumpfile -l --message-level 1 -d 31". -# For core_collector format details please refer to +# +# If "makedumpfile -F" is used then you will get a flattened +# format vmcore.flat. You will need to use "makedumpfile -R" +# to rearrange the dump data from standard input to a normal +# dumpfile (readable with analysis tools). For example: +# "makedumpfile -R vmcore < vmcore.flat". +# +# For core_collector format details, you can refer to # kexec-kdump-howto.txt or kdump.conf manpage. # # kdump_post <binary | script> -# - This directive allows you to run a specified -# executable just after the memory dump process -# terminates. The exit status from the dump process -# is fed to the kdump_post executable, which can be -# used to trigger different actions for success or -# failure. +# - This directive allows you to run a specified executable +# just after the vmcore dump process terminates. The exit +# status of the current dump process is fed to the kdump_post +# executable as its first argument($1). Executable can modify +# it to indicate the new exit status of succeeding dump process. # # kdump_pre <binary | script> -# - works just like the kdump_post directive, but instead +# - Works just like the "kdump_post" directive, but instead # of running after the dump process, runs immediately # before. Exit status of this binary is interpreted # as follows: @@ -84,7 +94,7 @@ # extra_bins <binaries | shell scripts> # - This directive allows you to specify additional # binaries or shell scripts you'd like to include in -# your kdump initrd. Generally only useful in +# your kdump initrd. Generally only useful in # conjunction with a kdump_post binary or script that # relies on other binaries or scripts. # @@ -93,41 +103,37 @@ # modules that you want to be loaded in the kdump # initrd, typically used to set up access to # non-boot-path dump targets that might otherwise -# not be accessible in the kdump environment. Multiple -# modules can be listed, separated by a space, and any +# not be accessible in the kdump environment. Multiple +# modules can be listed, separated by spaces, and any # dependent modules will automatically be included. # # default <reboot | halt | poweroff | shell | dump_to_rootfs> -# - Action to preform in case dumping to intended target -# fails. If no default action is specified, "reboot" -# is assumed default. -# reboot: If the default action is reboot simply reboot -# the system and loose the core that you are -# trying to retrieve. -# halt: If the default action is halt, then simply -# halt the system after attempting to capture -# a vmcore, regardless of success or failure. -# poweroff: The system will be powered down -# shell: If the default action is shell, then drop to -# an shell session inside the initramfs from -# where you can try to record the core manually. -# Exiting this shell reboots the system. -# Note: kdump uses bash as the default shell. +# - Action to perform in case dumping to the intended target +# fails. The default is "reboot". +# reboot: Reboot the system (this is what most people will +# want, as it returns the system to a nominal state). +# halt: Halt the system and lose the vmcore. +# poweroff: The system will be powered down. +# shell: Drop to a shell session inside the initramfs, +# from which you can try to save the core manually. +# Exiting this shell reboots the system. +# Note: kdump uses bash as the default shell. # dump_to_rootfs: If non-root dump target is specified, -# the default action can be set as dump_to_rootfs. -# That means when dump to target fails, dump vmcore -# to rootfs from initramfs context and reboot. +# the default action can be set as dump_to_rootfs. +# That means when dumping to target fails, dump vmcore +# to rootfs from initramfs context and reboot. # # force_rebuild <0 | 1> -# - By default, kdump initrd only will be rebuilt when -# necessary. Specify 1 to force rebuilding kdump +# - By default, kdump initrd will only be rebuilt when +# necessary. Specify 1 to force rebuilding kdump # initrd every time when kdump service starts. # -#override_resettable <0 | 1> -# - Usually a unresettable block device can't be dump target. -# Specifying 1 means though block target is unresettable, user -# understand this situation and want to try dumping. By default, -# it's set to 0, means not to try a destined failure. +# override_resettable <0 | 1> +# - Usually an unresettable block device can't be a dump +# target. Specifying 1 means that even though the block +# target is unresettable, the user wants to try dumping +# anyway. By default, it's set to 0, which will not try +# something destined to fail. # # dracut_args <arg(s)> # - Pass extra dracut options when rebuilding kdump @@ -135,11 +141,12 @@ # # fence_kdump_args <arg(s)> # - Command line arguments for fence_kdump_send (it can contain -# all valid arguments except hosts to send notification to). +# all valid arguments except hosts to send notification to). # # fence_kdump_nodes <node(s)> -# - List of cluster node(s) separated by space to send fence_kdump -# notification to (this option is mandatory to enable fence_kdump). +# - List of cluster node(s), separated by spaces, to send +# fence_kdump notifications to (this option is mandatory to +# enable fence_kdump). #
#raw /dev/vg/lv_kdump
Fix the typos and grammar problems in kdump.conf man page.
Reported-by: Donald Berry dberry@redhat.com Signed-off-by: Xunlei Pang xlpang@redhat.com --- kdump.conf.5 | 113 ++++++++++++++++++++++++++++------------------------------- 1 file changed, 54 insertions(+), 59 deletions(-)
diff --git a/kdump.conf.5 b/kdump.conf.5 index f1c2a2c..ca42769 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -10,14 +10,14 @@ collection service.
kdump.conf provides post-kexec instructions to the kdump kernel. It is stored in the initrd file managed by the kdump service. If you change -this file and do not want to restart before it takes effect, restart -the kdump service to rebuild to initrd. +this file and do not want to reboot in order for the changes to take +effect, restart the kdump service to rebuild the initrd.
For most configurations, you can simply review the examples provided in the stock /etc/kdump.conf.
.B NOTE: -For filesystem dump the dump target must be mounted before building +For filesystem dumps the dump target must be mounted before building kdump initramfs.
kdump.conf only affects the behavior of the initramfs. Please read the @@ -34,30 +34,30 @@ partition devices, such as /dev/vg/<devname>.
.B nfs <nfs mount> .RS -Will mount fs and copy /proc/vmcore to <mnt>/var/crash/%HOST-%DATE/, +Will mount nfs to <mnt>, and copy /proc/vmcore to <mnt>/<path>/%HOST-%DATE/, supports DNS. Note that a fqdn should be used as the server name in the -mount point +mount point. .RE
.B ssh user@server .RS -Will scp /proc/vmcore to user@server:/var/crash/%HOST-%DATE/, +Will scp /proc/vmcore to user@server:<path>/%HOST-%DATE/, supports DNS. NOTE: make sure user has necessary write permissions on -server and that a fqdn is used as the server name +server and that a fqdn is used as the server name. .RE
.B sshkey <path> .RS -Specifies the path of the ssh key you want to use when do ssh dump, -the default value is /root/.ssh/kdump_id_rsa. +Specify the path of the ssh key to use when dumping via ssh. +The default value is /root/.ssh/kdump_id_rsa. .RE
.B <fs type> <partition> .RS -Will mount -t <fs type> <partition> /mnt and copy /proc/vmcore to -/mnt/var/crash/%DATE/. NOTE: <partition> can be a device node, label +Will mount -t <fs type> <partition> <mnt>, and copy /proc/vmcore to +<mnt>/<path>/%DATE/. NOTE: <partition> can be a device node, label or uuid. It's recommended to use persistent device names such as -/dev/vg/<devname>. Otherwise it's suggested to use label or uuid. +/dev/vg/<devname>. Otherwise it's suggested to use label or uuid. .RE
.B path <path> @@ -66,37 +66,36 @@ or uuid. It's recommended to use persistent device names such as If a dump target is specified in kdump.conf, then "path" is relative to the specified dump target. .PP -Interpretation of path changes a bit if user has not specified a dump +Interpretation of "path" changes a bit if the user didn't specify any dump target explicitly in kdump.conf. In this case, "path" represents the -absolute path from root. And dump target and adjusted path are arrived +absolute path from root. The dump target and adjusted path are arrived at automatically depending on what's mounted in the current system. .PP -Ignored for raw device dumps. If unset, will default to /var/crash. +Ignored for raw device dumps. If unset, will use the default "/var/crash". .RE
.B core_collector <command> <options> .RS This allows you to specify the command to copy the vmcore. -You could use the dump filtering program makedumpfile, the default one, -to retrieve your core, which on some arches can drastically reduce -core file size. See /sbin/makedumpfile --help for a list of options. +The default is makedumpfile, which on some architectures can drastically reduce +core file size. See /sbin/makedumpfile --help for a list of options. Note that the -i and -g options are not needed here, as the initrd will automatically be populated with a config file appropriate for the running kernel. .PP Note 1: About default core collector: -Default core_collector for raw/ssh dump is: +The default core_collector for raw/ssh dump is: "makedumpfile -F -l --message-level 1 -d 31". -Default core_collector for other targets is: +The default core_collector for other targets is: "makedumpfile -l --message-level 1 -d 31". Even if core_collector option is commented out in kdump.conf, makedumpfile -is default core collector and kdump uses it internally. +is the default core collector and kdump uses it internally. If one does not want makedumpfile as default core_collector, then they need to specify one using core_collector option to change the behavior. .PP Note 2: If "makedumpfile -F" is used then you will get a flattened format vmcore.flat, you will need to use "makedumpfile -R" to rearrange the -dump data from stdard input to a normal dumpfile (readable with analysis +dump data from standard input to a normal dumpfile (readable with analysis tools). ie. "makedumpfile -R vmcore < vmcore.flat"
@@ -104,20 +103,19 @@ ie. "makedumpfile -R vmcore < vmcore.flat"
.B kdump_post <binary | script> .RS -This directive allows you to run a specified -executable just after the memory dump process -terminates. The exit status from the dump process -is fed to the kdump_post executable, which can be -used to trigger different actions for success or -failure. +This directive allows you to run a specified executable +just after the vmcore dump process terminates. The exit +status of the current dump process is fed to the kdump_post +executable as its first argument($1). Executable can modify +it to indicate the new exit status of succeeding dump process, .PP -Note that scripts written for use with this -directive must use the /bin/bash interpreter +Note that scripts written for use with this directive must use +the /bin/bash interpreter. .RE
.B kdump_pre <binary | script> .RS -Works just like the kdump_post directive, but instead +Works just like the "kdump_post" directive, but instead of running after the dump process, runs immediately before. Exit status of this binary is interpreted as follows: @@ -127,7 +125,7 @@ as follows: non 0 - reboot the system .PP Note that scripts written for this directive must use -the /bin/bash interpreter +the /bin/bash interpreter. .RE
.B extra_bins <binaries | shell scripts> @@ -146,36 +144,33 @@ modules that you want to be loaded in the kdump initrd, typically used to set up access to non-boot-path dump targets that might otherwise not be accessible in the kdump environment. Multiple -modules can be listed, separated by a space, and any +modules can be listed, separated by spaces, and any dependent modules will automatically be included. .RE
.B default <reboot | halt | poweroff | shell | dump_to_rootfs> .RS -Action to preform in case dumping to intended target fails. If no default -action is specified, "reboot" is assumed default. -reboot: If the default action is reboot simply reboot the system (this is what -most people will want, as it returns the system to a nominal state). shell: If the default -action is shell, then drop to an shell session inside the initramfs from -where you can manually preform additional recovery actions. Exiting this shell -reboots the system. halt: bring the system to a halt, requiring manual reset -poweroff: The system will be powered down. dump_to_rootfs:If the default action -is dump_to_rootfs, specified root will be mounted and dump will be saved in "path" -directory. -Note: kdump uses bash as the default shell. +Action to perform in case dumping to the intended target fails. The default is "reboot". +reboot: Reboot the system (this is what most people will want, as it returns the system +to a normal state). halt: Halt the system and lose the vmcore. poweroff: The system +will be powered down. shell: Drop to a shell session inside the initramfs, from which +you can manually perform additional recovery actions. Exiting this shell reboots the +system. Note: kdump uses bash as the default shell. dump_to_rootfs: If non-root dump +target is specified, the default action can be set as dump_to_rootfs. That means when +dumping to target fails, dump vmcore to rootfs from initramfs context and reboot. .RE
.B force_rebuild <0 | 1> .RS -By default, kdump initrd only will be rebuilt when necessary. +By default, kdump initrd will only be rebuilt when necessary. Specify 1 to force rebuilding kdump initrd every time when kdump service starts. .RE
.B override_resettable <0 | 1> .RS -Usually a unresettable block device can't be dump target. Specifying 1 means -though block target is unresettable, user understand this situation and want -to try dumping. By default, it's set to 0, means not to try a destined failure. +Usually an unresettable block device can't be a dump target. Specifying 1 means +that even though the block target is unresettable, the user wants to try dumping anyway. +By default, it's set to 0, which will not try something destined to fail. .RE
@@ -195,7 +190,7 @@ arguments except hosts to send notification to).
.B fence_kdump_nodes <node(s)> .RS -List of cluster node(s) separated by space to send fence_kdump notification +List of cluster node(s), separated by spaces, to send fence_kdump notification to (this option is mandatory to enable fence_kdump). .RE
@@ -210,26 +205,26 @@ directly.
.B options <module> <option list> .RS -Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump to add proper -module option as kernel command line params. Such as append loop.max_loop=1 -to limit maximum loop devices to 1. +Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump to add module options as +kernel command line parameters. For example, specify 'loop.max_loop=1' to limit +maximum loop devices to 1. .RE
.B link_delay <seconds> .RS -link_delay was used to wait a network device to initialize before using it. -Now dracut network module take care of this issue automaticlly. +link_delay was used to wait for a network device to initialize before using it. +Now dracut network module takes care of this issue automatically. .RE
.B disk_timeout <seconds> .RS -Similar to link_delay, dracut ensures disks being ready before kdump uses them. +Similar to link_delay, dracut ensures disks are ready before kdump uses them. .RE
.B debug_mem_level <0-3> .RS -This was used to turns on debug/verbose output of kdump scripts regarding -free/used memory at various points of execution. This feature has been +Turn on verbose debug output of kdump scripts regarding free/used memory at +various points of execution. This feature has been moved to dracut now. Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump and append dracut cmdline param rd.memdebug=[0-3] to enable the debug output. @@ -253,7 +248,7 @@ present in initramfs but it is not actually loaded in kernel. Hence retaining blacklist option creates more confusing behavior. It has been deprecated. .PP -Instead use rd.driver.blacklist option on second kernel to blacklist +Instead, use rd.driver.blacklist option on second kernel to blacklist a certain module. One can edit /etc/sysconfig/kdump.conf and edit KDUMP_COMMANDLINE_APPEND to pass kernel command line options. Refer to dracut.cmdline man page for more details on module blacklist option. @@ -262,7 +257,7 @@ to dracut.cmdline man page for more details on module blacklist option. .RE
.SH EXAMPLES -Here is some examples for core_collector option: +Here are some examples for core_collector option: .PP Core collector command format depends on dump target type. Typically for filesystem (local/remote), core_collector should accept two arguments.
On 07/06/16 at 01:02pm, Xunlei Pang wrote:
This was formerly done by Freeman, now I take it over with a few further fixes.
Xunlei Pang (2): kdump.conf comments fixes kdump.conf man page fixes
Go through patches once, looks good to me. Anyway it can be fixed later if any improvement can be made. Document issue is not critical or block something, so I am fine with this patchset , ack it now.
Acked-by: Baoquan He bhe@redhat.com
Thanks Baoquan
kdump.conf | 193 +++++++++++++++++++++++++++++++---------------------------- kdump.conf.5 | 113 +++++++++++++++++----------------- 2 files changed, 154 insertions(+), 152 deletions(-)
-- 1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Hi, Donald
Could you check this verion from Xunlei, if everything is ok I will merge it in Fedora repo.
Thanks Dave On 07/06/16 at 01:02pm, Xunlei Pang wrote:
This was formerly done by Freeman, now I take it over with a few further fixes.
Xunlei Pang (2): kdump.conf comments fixes kdump.conf man page fixes
kdump.conf | 193 +++++++++++++++++++++++++++++++---------------------------- kdump.conf.5 | 113 +++++++++++++++++----------------- 2 files changed, 154 insertions(+), 152 deletions(-)
-- 1.8.3.1 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Hi, Xunlei
On 07/06/16 at 01:02pm, Xunlei Pang wrote:
This was formerly done by Freeman, now I take it over with a few further fixes.
Xunlei Pang (2): kdump.conf comments fixes kdump.conf man page fixes
kdump.conf | 193 +++++++++++++++++++++++++++++++---------------------------- kdump.conf.5 | 113 +++++++++++++++++----------------- 2 files changed, 154 insertions(+), 152 deletions(-)
Applied with fixes to trailing whitespaces, over 80 columns lines, alighment issues, cleaned up several unnecessary words.
Thanks Dave
On 07/20/16 at 10:14am, Dave Young wrote:
Hi, Xunlei
On 07/06/16 at 01:02pm, Xunlei Pang wrote:
This was formerly done by Freeman, now I take it over with a few further fixes.
Xunlei Pang (2): kdump.conf comments fixes kdump.conf man page fixes
kdump.conf | 193 +++++++++++++++++++++++++++++++---------------------------- kdump.conf.5 | 113 +++++++++++++++++----------------- 2 files changed, 154 insertions(+), 152 deletions(-)
Applied with fixes to trailing whitespaces, over 80 columns lines, alighment issues, cleaned up several unnecessary words.
Also replaced all tabs with spaces so that they can align correctly.
Thanks Dave _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org