If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com --- kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;; + final_action) + case $config_val in + reboot) + FINAL_ACTION="systemctl reboot -f" + ;; + halt) + FINAL_ACTION="halt" + ;; + poweroff) + FINAL_ACTION="systemctl poweroff -f" + ;; + esac + ;; esac done < $KDUMP_CONF
diff --git a/kdump.conf b/kdump.conf index 286ad27..6643e87 100644 --- a/kdump.conf +++ b/kdump.conf @@ -110,6 +110,11 @@ # reboot. Useful when non-root dump target is specified. # The default option is "reboot". # +# final_action <reboot | halt | poweroff> +# - Action to perform in case dumping succeeds. +# Each action is same as the "default" directive above. +# The default is "reboot". +# # force_rebuild <0 | 1> # - By default, kdump initrd will only be rebuilt when necessary. # Specify 1 to force rebuilding kdump initrd every time when kdump diff --git a/kdump.conf.5 b/kdump.conf.5 index 990076e..72995c4 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -160,6 +160,12 @@ target is specified, the default action can be set as dump_to_rootfs. That mean dumping to target fails, dump vmcore to rootfs from initramfs context and reboot. .RE
+.B final_action <reboot | halt | poweroff> +.RS +Action to perform in case dumping to the intended target succeeds. The default is +"reboot". Each action is same as the "default" directive above. +.RE + .B force_rebuild <0 | 1> .RS By default, kdump initrd will only be rebuilt when necessary. diff --git a/kdumpctl b/kdumpctl index ca47705..992aaa8 100755 --- a/kdumpctl +++ b/kdumpctl @@ -228,7 +228,7 @@ check_config() case "$config_opt" in #* | "") ;; - raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes) + raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|final_action|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes) # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) [ -z "$config_val" ] && { @@ -248,6 +248,7 @@ check_config() done < $KDUMP_CONFIG_FILE
check_default_config || return 1 + check_final_action_config || return 1
check_fence_kdump_config || return 1
@@ -954,6 +955,25 @@ check_default_config() fi }
+check_final_action_config() +{ + local final_action + + final_action=$(awk '$1 ~ /^final_action$/ {print $2;}' $KDUMP_CONFIG_FILE) + if [ -z "$final_action" ]; then + return 0 + else + case "$final_action" in + reboot|halt|poweroff) + return 0 + ;; + *) + echo $"Usage kdump.conf: final_action {reboot|halt|poweroff}" + return 1 + esac + fi +} + start() { check_dump_feasibility
Since early kdump is generally used for capturing vmcore when boot-time panic occurs, if a system always reboots after capturing vmcore, it can go into a crash loop.
To avoid this issue, this patch add a note on 'final_action' option to the early kdump document.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com --- early-kdump-howto.txt | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/early-kdump-howto.txt b/early-kdump-howto.txt index fe4f13f..6da6220 100644 --- a/early-kdump-howto.txt +++ b/early-kdump-howto.txt @@ -1,6 +1,7 @@ Early Kdump HOWTO
Introduction +------------
Kdump service starts too late, so early crashes will have no chance to get kdump kernel booting, this will cause crash information to be lost. It is @@ -12,7 +13,8 @@ which is disabled by default. For the normal kdump service, it can check whether the early kdump has loaded the crash kernel and initramfs. It has no conflict with the early kdump.
-How to configure early kdump: +How to configure early kdump +----------------------------
We assume if you're reading this document, you should already have kexec-tools installed. @@ -21,6 +23,14 @@ You can rebuild the initramfs with earlykdump support with below steps: 1. start kdump service to make sure kdump initramfs is created. # systemctl start kdump
+ NOTE: If a crash occurs during boot process, early kdump captures a vmcore + and reboot the system by default, so the system might go into crash loop. + You can avoid such a crash loop by adding the following settings, which + power off the system after dump capturing, to kdump.conf in advance: + + final_action poweroff + default poweroff + 2. rebuild system initramfs with earlykdump support. # dracut --add earlykdump
@@ -50,5 +60,6 @@ kdump kernel Mar 09 10:02:47 localhost.localdomain dracut-cmdline[189]: early-kdump is disabled.
Limitation +----------
At present, early kdump doesn't support fadump.
Hi Kazu, On 01/09/19 at 03:38pm, Kazuhito Hagio wrote:
Since early kdump is generally used for capturing vmcore when boot-time panic occurs, if a system always reboots after capturing vmcore, it can go into a crash loop.
To avoid this issue, this patch add a note on 'final_action' option to the early kdump document.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
early-kdump-howto.txt | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/early-kdump-howto.txt b/early-kdump-howto.txt index fe4f13f..6da6220 100644 --- a/early-kdump-howto.txt +++ b/early-kdump-howto.txt @@ -1,6 +1,7 @@ Early Kdump HOWTO
Introduction +------------
Kdump service starts too late, so early crashes will have no chance to get kdump kernel booting, this will cause crash information to be lost. It is @@ -12,7 +13,8 @@ which is disabled by default. For the normal kdump service, it can check whether the early kdump has loaded the crash kernel and initramfs. It has no conflict with the early kdump.
-How to configure early kdump: +How to configure early kdump +----------------------------
We assume if you're reading this document, you should already have kexec-tools installed. @@ -21,6 +23,14 @@ You can rebuild the initramfs with earlykdump support with below steps:
- start kdump service to make sure kdump initramfs is created. # systemctl start kdump
- NOTE: If a crash occurs during boot process, early kdump captures a vmcore
- and reboot the system by default, so the system might go into crash loop.
- You can avoid such a crash loop by adding the following settings, which
- power off the system after dump capturing, to kdump.conf in advance:
final_action poweroffdefault poweroff
'default' can be anything other than "reboot", so it would be better to describe it here.
- rebuild system initramfs with earlykdump support. # dracut --add earlykdump
@@ -50,5 +60,6 @@ kdump kernel Mar 09 10:02:47 localhost.localdomain dracut-cmdline[189]: early-kdump is disabled.
Limitation +----------
At present, early kdump doesn't support fadump.
2.18.0
Thanks Dave
On 1/10/2019 12:53 AM, Dave Young wrote:
Hi Kazu, On 01/09/19 at 03:38pm, Kazuhito Hagio wrote:
Since early kdump is generally used for capturing vmcore when boot-time panic occurs, if a system always reboots after capturing vmcore, it can go into a crash loop.
To avoid this issue, this patch add a note on 'final_action' option to the early kdump document.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
early-kdump-howto.txt | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/early-kdump-howto.txt b/early-kdump-howto.txt index fe4f13f..6da6220 100644 --- a/early-kdump-howto.txt +++ b/early-kdump-howto.txt @@ -1,6 +1,7 @@ Early Kdump HOWTO
Introduction +------------
Kdump service starts too late, so early crashes will have no chance to get kdump kernel booting, this will cause crash information to be lost. It is @@ -12,7 +13,8 @@ which is disabled by default. For the normal kdump service, it can check whether the early kdump has loaded the crash kernel and initramfs. It has no conflict with the early kdump.
-How to configure early kdump: +How to configure early kdump +----------------------------
We assume if you're reading this document, you should already have kexec-tools installed. @@ -21,6 +23,14 @@ You can rebuild the initramfs with earlykdump support with below steps:
- start kdump service to make sure kdump initramfs is created. # systemctl start kdump
- NOTE: If a crash occurs during boot process, early kdump captures a vmcore
- and reboot the system by default, so the system might go into crash loop.
- You can avoid such a crash loop by adding the following settings, which
- power off the system after dump capturing, to kdump.conf in advance:
final_action poweroffdefault poweroff'default' can be anything other than "reboot", so it would be better to describe it here.
Thank you. I think "dump_to_rootfs" also might be dangerous in this case, so will exclude "reboot" and "dump_to_rootfs".
Thanks, Kazu
在 2019年01月10日 04:38, Kazuhito Hagio 写道:
If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;;
final_action)case $config_val inreboot)FINAL_ACTION="systemctl reboot -f";;halt)FINAL_ACTION="halt";;poweroff)FINAL_ACTION="systemctl poweroff -f";;esac;; esac
Thanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Not sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() { - echo "Kdump: Executing default action $DEFAULT_ACTION" - eval $DEFAULT_ACTION + if [ "$DEFAULT_ACTION" == "" ]; then + echo "Kdump: default action is not set." + else + echo "Kdump: Executing default action $DEFAULT_ACTION" + eval $DEFAULT_ACTION + fi }
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Thanks Lianbo
diff --git a/kdump.conf b/kdump.conf index 286ad27..6643e87 100644 --- a/kdump.conf +++ b/kdump.conf @@ -110,6 +110,11 @@ # reboot. Useful when non-root dump target is specified. # The default option is "reboot". # +# final_action <reboot | halt | poweroff> +# - Action to perform in case dumping succeeds. +# Each action is same as the "default" directive above. +# The default is "reboot". +# # force_rebuild <0 | 1> # - By default, kdump initrd will only be rebuilt when necessary. # Specify 1 to force rebuilding kdump initrd every time when kdump diff --git a/kdump.conf.5 b/kdump.conf.5 index 990076e..72995c4 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -160,6 +160,12 @@ target is specified, the default action can be set as dump_to_rootfs. That mean dumping to target fails, dump vmcore to rootfs from initramfs context and reboot. .RE
+.B final_action <reboot | halt | poweroff> +.RS +Action to perform in case dumping to the intended target succeeds. The default is +"reboot". Each action is same as the "default" directive above. +.RE
.B force_rebuild <0 | 1> .RS By default, kdump initrd will only be rebuilt when necessary. diff --git a/kdumpctl b/kdumpctl index ca47705..992aaa8 100755 --- a/kdumpctl +++ b/kdumpctl @@ -228,7 +228,7 @@ check_config() case "$config_opt" in #* | "") ;;
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes)
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|final_action|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes) # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) [ -z "$config_val" ] && {@@ -248,6 +248,7 @@ check_config() done < $KDUMP_CONFIG_FILE
check_default_config || return 1
check_final_action_config || return 1
check_fence_kdump_config || return 1
@@ -954,6 +955,25 @@ check_default_config() fi }
+check_final_action_config() +{
- local final_action
- final_action=$(awk '$1 ~ /^final_action$/ {print $2;}' $KDUMP_CONFIG_FILE)
- if [ -z "$final_action" ]; then
return 0- else
case "$final_action" inreboot|halt|poweroff)return 0;;*)echo $"Usage kdump.conf: final_action {reboot|halt|poweroff}"return 1esac- fi
+}
start() { check_dump_feasibility
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 04:38, Kazuhito Hagio 写道:
If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;;
final_action)case $config_val inreboot)FINAL_ACTION="systemctl reboot -f";;halt)FINAL_ACTION="halt";;poweroff)FINAL_ACTION="systemctl poweroff -f";;esac;; esacThanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Not sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() {
- echo "Kdump: Executing default action $DEFAULT_ACTION"
- eval $DEFAULT_ACTION
- if [ "$DEFAULT_ACTION" == "" ]; then
echo "Kdump: default action is not set."- else
echo "Kdump: Executing default action $DEFAULT_ACTION"eval $DEFAULT_ACTION- fi
}
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Just my personal p-o-v.
Thanks, Bhupesh
Thanks Lianbo
diff --git a/kdump.conf b/kdump.conf index 286ad27..6643e87 100644 --- a/kdump.conf +++ b/kdump.conf @@ -110,6 +110,11 @@ # reboot. Useful when non-root dump target is specified. # The default option is "reboot". # +# final_action <reboot | halt | poweroff> +# - Action to perform in case dumping succeeds. +# Each action is same as the "default" directive above. +# The default is "reboot". +# # force_rebuild <0 | 1> # - By default, kdump initrd will only be rebuilt when necessary. # Specify 1 to force rebuilding kdump initrd every time when kdump diff --git a/kdump.conf.5 b/kdump.conf.5 index 990076e..72995c4 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -160,6 +160,12 @@ target is specified, the default action can be set as dump_to_rootfs. That mean dumping to target fails, dump vmcore to rootfs from initramfs context and reboot. .RE
+.B final_action <reboot | halt | poweroff> +.RS +Action to perform in case dumping to the intended target succeeds. The default is +"reboot". Each action is same as the "default" directive above. +.RE
.B force_rebuild <0 | 1> .RS By default, kdump initrd will only be rebuilt when necessary. diff --git a/kdumpctl b/kdumpctl index ca47705..992aaa8 100755 --- a/kdumpctl +++ b/kdumpctl @@ -228,7 +228,7 @@ check_config() case "$config_opt" in #* | "") ;;
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes)
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|final_action|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes) # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) [ -z "$config_val" ] && {@@ -248,6 +248,7 @@ check_config() done < $KDUMP_CONFIG_FILE
check_default_config || return 1
check_final_action_config || return 1 check_fence_kdump_config || return 1@@ -954,6 +955,25 @@ check_default_config() fi }
+check_final_action_config() +{
local final_actionfinal_action=$(awk '$1 ~ /^final_action$/ {print $2;}' $KDUMP_CONFIG_FILE)if [ -z "$final_action" ]; thenreturn 0elsecase "$final_action" inreboot|halt|poweroff)return 0;;*)echo $"Usage kdump.conf: final_action {reboot|halt|poweroff}"return 1esacfi+}
start() { check_dump_feasibility
kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
在 2019年01月10日 14:59, Bhupesh Sharma 写道:
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 04:38, Kazuhito Hagio 写道:
If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;;
final_action)case $config_val inreboot)FINAL_ACTION="systemctl reboot -f";;halt)FINAL_ACTION="halt";;poweroff)FINAL_ACTION="systemctl poweroff -f";;esac;; esacThanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Not sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() {
- echo "Kdump: Executing default action $DEFAULT_ACTION"
- eval $DEFAULT_ACTION
- if [ "$DEFAULT_ACTION" == "" ]; then
echo "Kdump: default action is not set."- else
echo "Kdump: Executing default action $DEFAULT_ACTION"eval $DEFAULT_ACTION- fi
}
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Thanks. Lianbo
Just my personal p-o-v.
Thanks, Bhupesh
Thanks Lianbo
diff --git a/kdump.conf b/kdump.conf index 286ad27..6643e87 100644 --- a/kdump.conf +++ b/kdump.conf @@ -110,6 +110,11 @@ # reboot. Useful when non-root dump target is specified. # The default option is "reboot". # +# final_action <reboot | halt | poweroff> +# - Action to perform in case dumping succeeds. +# Each action is same as the "default" directive above. +# The default is "reboot". +# # force_rebuild <0 | 1> # - By default, kdump initrd will only be rebuilt when necessary. # Specify 1 to force rebuilding kdump initrd every time when kdump diff --git a/kdump.conf.5 b/kdump.conf.5 index 990076e..72995c4 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -160,6 +160,12 @@ target is specified, the default action can be set as dump_to_rootfs. That mean dumping to target fails, dump vmcore to rootfs from initramfs context and reboot. .RE
+.B final_action <reboot | halt | poweroff> +.RS +Action to perform in case dumping to the intended target succeeds. The default is +"reboot". Each action is same as the "default" directive above. +.RE
.B force_rebuild <0 | 1> .RS By default, kdump initrd will only be rebuilt when necessary. diff --git a/kdumpctl b/kdumpctl index ca47705..992aaa8 100755 --- a/kdumpctl +++ b/kdumpctl @@ -228,7 +228,7 @@ check_config() case "$config_opt" in #* | "") ;;
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes)
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|final_action|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes) # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) [ -z "$config_val" ] && {@@ -248,6 +248,7 @@ check_config() done < $KDUMP_CONFIG_FILE
check_default_config || return 1
check_final_action_config || return 1 check_fence_kdump_config || return 1@@ -954,6 +955,25 @@ check_default_config() fi }
+check_final_action_config() +{
local final_actionfinal_action=$(awk '$1 ~ /^final_action$/ {print $2;}' $KDUMP_CONFIG_FILE)if [ -z "$final_action" ]; thenreturn 0elsecase "$final_action" inreboot|halt|poweroff)return 0;;*)echo $"Usage kdump.conf: final_action {reboot|halt|poweroff}"return 1esacfi+}
start() { check_dump_feasibility
kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
On Thu, Jan 10, 2019 at 6:28 PM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 14:59, Bhupesh Sharma 写道:
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 04:38, Kazuhito Hagio 写道:
If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;;
final_action)case $config_val inreboot)FINAL_ACTION="systemctl reboot -f";;halt)FINAL_ACTION="halt";;poweroff)FINAL_ACTION="systemctl poweroff -f";;esac;; esacThanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Not sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() {
- echo "Kdump: Executing default action $DEFAULT_ACTION"
- eval $DEFAULT_ACTION
- if [ "$DEFAULT_ACTION" == "" ]; then
echo "Kdump: default action is not set."- else
echo "Kdump: Executing default action $DEFAULT_ACTION"eval $DEFAULT_ACTION- fi
}
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
Regards, Bhupesh
Just my personal p-o-v.
Thanks, Bhupesh
Thanks Lianbo
diff --git a/kdump.conf b/kdump.conf index 286ad27..6643e87 100644 --- a/kdump.conf +++ b/kdump.conf @@ -110,6 +110,11 @@ # reboot. Useful when non-root dump target is specified. # The default option is "reboot". # +# final_action <reboot | halt | poweroff> +# - Action to perform in case dumping succeeds. +# Each action is same as the "default" directive above. +# The default is "reboot". +# # force_rebuild <0 | 1> # - By default, kdump initrd will only be rebuilt when necessary. # Specify 1 to force rebuilding kdump initrd every time when kdump diff --git a/kdump.conf.5 b/kdump.conf.5 index 990076e..72995c4 100644 --- a/kdump.conf.5 +++ b/kdump.conf.5 @@ -160,6 +160,12 @@ target is specified, the default action can be set as dump_to_rootfs. That mean dumping to target fails, dump vmcore to rootfs from initramfs context and reboot. .RE
+.B final_action <reboot | halt | poweroff> +.RS +Action to perform in case dumping to the intended target succeeds. The default is +"reboot". Each action is same as the "default" directive above. +.RE
.B force_rebuild <0 | 1> .RS By default, kdump initrd will only be rebuilt when necessary. diff --git a/kdumpctl b/kdumpctl index ca47705..992aaa8 100755 --- a/kdumpctl +++ b/kdumpctl @@ -228,7 +228,7 @@ check_config() case "$config_opt" in #* | "") ;;
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes)
raw|ext2|ext3|ext4|minix|btrfs|xfs|nfs|ssh|sshkey|path|core_collector|kdump_post|kdump_pre|extra_bins|extra_modules|default|final_action|force_rebuild|force_no_rebuild|dracut_args|fence_kdump_args|fence_kdump_nodes) # remove inline comments after the end of a directive. config_val=$(strip_comments $config_val) [ -z "$config_val" ] && {@@ -248,6 +248,7 @@ check_config() done < $KDUMP_CONFIG_FILE
check_default_config || return 1
check_final_action_config || return 1 check_fence_kdump_config || return 1@@ -954,6 +955,25 @@ check_default_config() fi }
+check_final_action_config() +{
local final_actionfinal_action=$(awk '$1 ~ /^final_action$/ {print $2;}' $KDUMP_CONFIG_FILE)if [ -z "$final_action" ]; thenreturn 0elsecase "$final_action" inreboot|halt|poweroff)return 0;;*)echo $"Usage kdump.conf: final_action {reboot|halt|poweroff}"return 1esacfi+}
start() { check_dump_feasibility
kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Hi Lianbo, Bhupesh
Thank you for the comments.
On 1/10/2019 2:40 PM, Bhupesh Sharma wrote:
On Thu, Jan 10, 2019 at 6:28 PM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 14:59, Bhupesh Sharma 写道:
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 04:38, Kazuhito Hagio 写道:
If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;;
final_action)case $config_val inreboot)FINAL_ACTION="systemctl reboot -f";;halt)FINAL_ACTION="halt";;poweroff)FINAL_ACTION="systemctl poweroff -f";;esac;; esacThanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Yes, this is why I wrote the following in the 2/2 patch.
+ final_action poweroff + default poweroff
Not sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() {
- echo "Kdump: Executing default action $DEFAULT_ACTION"
- eval $DEFAULT_ACTION
- if [ "$DEFAULT_ACTION" == "" ]; then
echo "Kdump: default action is not set."- else
echo "Kdump: Executing default action $DEFAULT_ACTION"eval $DEFAULT_ACTION- fi
}
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Yes, but we shouldn't change the default value of 'default' option because many users would be confused by the change.
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
I also think the current terms are confusing and something like 'success_action' and 'failure_action' might be more intuitive.
So an idea I thought of is adding 'failure_action' as an alias of 'default' and removing 'default' in the future.
failure_action <reboot | halt | poweroff | shell | dump_to_rootfs> default <reboot | halt | poweroff | shell | dump_to_rootfs> - Action to perform in case dumping fails. No difference between "failure_action" and "default" but "default" directive will be removed in the future.
success_action <reboot | halt | poweroff> - Action to perform in case dumping succeeds.
Any other ideas?
Thanks, Kazu
在 2019年01月11日 05:41, Kazuhito Hagio 写道:
Hi Lianbo, Bhupesh
Thank you for the comments.
On 1/10/2019 2:40 PM, Bhupesh Sharma wrote:
On Thu, Jan 10, 2019 at 6:28 PM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 14:59, Bhupesh Sharma 写道:
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 04:38, Kazuhito Hagio 写道:
If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;;
final_action)case $config_val inreboot)FINAL_ACTION="systemctl reboot -f";;halt)FINAL_ACTION="halt";;poweroff)FINAL_ACTION="systemctl poweroff -f";;esac;; esacThanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Yes, this is why I wrote the following in the 2/2 patch.
final_action poweroffdefault poweroffNot sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() {
- echo "Kdump: Executing default action $DEFAULT_ACTION"
- eval $DEFAULT_ACTION
- if [ "$DEFAULT_ACTION" == "" ]; then
echo "Kdump: default action is not set."- else
echo "Kdump: Executing default action $DEFAULT_ACTION"eval $DEFAULT_ACTION- fi
}
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Yes, but we shouldn't change the default value of 'default' option because many users would be confused by the change.
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
I also think the current terms are confusing and something like 'success_action' and 'failure_action' might be more intuitive.
So an idea I thought of is adding 'failure_action' as an alias of 'default' and removing 'default' in the future.
It looks good to me, because it only switches to the kdump-error-handler.sh when the dumping fails.
If the dumping succeeds, it will switch to the kdump.sh.
Thanks. Lianbo
failure_action <reboot | halt | poweroff | shell | dump_to_rootfs> default <reboot | halt | poweroff | shell | dump_to_rootfs> - Action to perform in case dumping fails. No difference between "failure_action" and "default" but "default" directive will be removed in the future.
success_action <reboot | halt | poweroff> - Action to perform in case dumping succeeds.
Any other ideas?
Thanks, Kazu
Hi Kazu,
On 01/10/19 at 04:41pm, Kazuhito Hagio wrote:
Hi Lianbo, Bhupesh
Thank you for the comments.
On 1/10/2019 2:40 PM, Bhupesh Sharma wrote:
On Thu, Jan 10, 2019 at 6:28 PM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 14:59, Bhupesh Sharma 写道:
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 04:38, Kazuhito Hagio 写道:
If a crash occurs repeatedly after enabling kdump, the system goes into a crash loop and the dump target may get filled up by vmcores. This is likely to happen especially with early kdump.
This patch introduces 'final_action' option to kdump.conf, in order for users to be able to power off the system even after capturing a vmcore successfully.
Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com Cc: Dave Young dyoung@redhat.com Cc: Lianbo Jiang lijiang@redhat.com
kdump-lib-initramfs.sh | 13 +++++++++++++ kdump.conf | 5 +++++ kdump.conf.5 | 6 ++++++ kdumpctl | 22 +++++++++++++++++++++- 4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index f5155a4..9f482cd 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -70,6 +70,19 @@ get_kdump_confs() ;; esac ;;
final_action)case $config_val inreboot)FINAL_ACTION="systemctl reboot -f";;halt)FINAL_ACTION="halt";;poweroff)FINAL_ACTION="systemctl poweroff -f";;esac;; esacThanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Yes, this is why I wrote the following in the 2/2 patch.
final_action poweroffdefault poweroffNot sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() {
- echo "Kdump: Executing default action $DEFAULT_ACTION"
- eval $DEFAULT_ACTION
- if [ "$DEFAULT_ACTION" == "" ]; then
echo "Kdump: default action is not set."- else
echo "Kdump: Executing default action $DEFAULT_ACTION"eval $DEFAULT_ACTION- fi
}
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Yes, but we shouldn't change the default value of 'default' option because many users would be confused by the change.
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
I also think the current terms are confusing and something like 'success_action' and 'failure_action' might be more intuitive.
So an idea I thought of is adding 'failure_action' as an alias of 'default' and removing 'default' in the future.
failure_action <reboot | halt | poweroff | shell | dump_to_rootfs> default <reboot | halt | poweroff | shell | dump_to_rootfs> - Action to perform in case dumping fails. No difference between "failure_action" and "default" but "default" directive will be removed in the future.
Sounds good, also should check these two can not coexist in kdump.conf
success_action <reboot | halt | poweroff> - Action to perform in case dumping succeeds.
succes_action is not very accurate, in case kdump failed "default" action runs, and after that final action still get change to run.
So final_action seems better.
Any other ideas?
Thanks, Kazu _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Thanks Dave
Dave, Lianbo,
Thank you for your comments.
On 1/11/2019 3:43 AM, Dave Young wrote:
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
I also think the current terms are confusing and something like 'success_action' and 'failure_action' might be more intuitive.
So an idea I thought of is adding 'failure_action' as an alias of 'default' and removing 'default' in the future.
failure_action <reboot | halt | poweroff | shell | dump_to_rootfs> default <reboot | halt | poweroff | shell | dump_to_rootfs> - Action to perform in case dumping fails. No difference between "failure_action" and "default" but "default" directive will be removed in the future.
Sounds good, also should check these two can not coexist in kdump.conf
OK, I'll add the check to the next patch.
success_action <reboot | halt | poweroff> - Action to perform in case dumping succeeds.
succes_action is not very accurate, in case kdump failed "default" action runs, and after that final action still get change to run.
So final_action seems better.
OK, will leave final_action as it is.
Thanks, Kazu
Hi Dave,
On Fri, Jan 11, 2019 at 2:13 PM Dave Young dyoung@redhat.com wrote:
Hi Kazu,
On 01/10/19 at 04:41pm, Kazuhito Hagio wrote:
Hi Lianbo, Bhupesh
Thank you for the comments.
On 1/10/2019 2:40 PM, Bhupesh Sharma wrote:
On Thu, Jan 10, 2019 at 6:28 PM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 14:59, Bhupesh Sharma 写道:
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 04:38, Kazuhito Hagio 写道: > If a crash occurs repeatedly after enabling kdump, the system goes > into a crash loop and the dump target may get filled up by vmcores. > This is likely to happen especially with early kdump. > > This patch introduces 'final_action' option to kdump.conf, in order > for users to be able to power off the system even after capturing > a vmcore successfully. > > Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com > Cc: Dave Young dyoung@redhat.com > Cc: Lianbo Jiang lijiang@redhat.com > --- > kdump-lib-initramfs.sh | 13 +++++++++++++ > kdump.conf | 5 +++++ > kdump.conf.5 | 6 ++++++ > kdumpctl | 22 +++++++++++++++++++++- > 4 files changed, 45 insertions(+), 1 deletion(-) > > diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh > index f5155a4..9f482cd 100755 > --- a/kdump-lib-initramfs.sh > +++ b/kdump-lib-initramfs.sh > @@ -70,6 +70,19 @@ get_kdump_confs() > ;; > esac > ;; > + final_action) > + case $config_val in > + reboot) > + FINAL_ACTION="systemctl reboot -f" > + ;; > + halt) > + FINAL_ACTION="halt" > + ;; > + poweroff) > + FINAL_ACTION="systemctl poweroff -f" > + ;; > + esac > + ;; > esac > done < $KDUMP_CONF > Thanks for your patch.
Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls the do_default_action() first, and then executes the final action. Because the default is always 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Yes, this is why I wrote the following in the 2/2 patch.
final_action poweroffdefault poweroffNot sure whether it would be more better like this:
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 7ba99b6..953b8bc 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" CORE_COLLECTOR="" DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" DMESG_COLLECTOR="/sbin/vmcore-dmesg" -DEFAULT_ACTION="systemctl reboot -f" +DEFAULT_ACTION=""
do_default_action() {
- echo "Kdump: Executing default action $DEFAULT_ACTION"
- eval $DEFAULT_ACTION
- if [ "$DEFAULT_ACTION" == "" ]; then
echo "Kdump: default action is not set."- else
echo "Kdump: Executing default action $DEFAULT_ACTION"eval $DEFAULT_ACTION- fi
}
It makes sure that the final action can be called in case user doesn't set the 'default poweroff' and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Yes, but we shouldn't change the default value of 'default' option because many users would be confused by the change.
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
I also think the current terms are confusing and something like 'success_action' and 'failure_action' might be more intuitive.
So an idea I thought of is adding 'failure_action' as an alias of 'default' and removing 'default' in the future.
failure_action <reboot | halt | poweroff | shell | dump_to_rootfs> default <reboot | halt | poweroff | shell | dump_to_rootfs> - Action to perform in case dumping fails. No difference between "failure_action" and "default" but "default" directive will be removed in the future.
Sounds good, also should check these two can not coexist in kdump.conf
success_action <reboot | halt | poweroff> - Action to perform in case dumping succeeds.
succes_action is not very accurate, in case kdump failed "default" action runs, and after that final action still get change to run.
So final_action seems better.
As I mentioned before, from a english reader p-o-v, default action implies 'the final preselected action in case no alternative is specified by the user or programmer'. Rather lets consider failsafe_action. By the english dictionary it means 'a system or plan that comes into operation in the event of something going wrong or that is in place to prevent such an occurrence.'
So in case kdump fails default action runs and after that failsafe action runs.
Thanks, Bhupesh
Any other ideas?
Thanks, Kazu _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Thanks Dave
On 01/13/19 at 04:59pm, Bhupesh Sharma wrote:
Hi Dave,
On Fri, Jan 11, 2019 at 2:13 PM Dave Young dyoung@redhat.com wrote:
Hi Kazu,
On 01/10/19 at 04:41pm, Kazuhito Hagio wrote:
Hi Lianbo, Bhupesh
Thank you for the comments.
On 1/10/2019 2:40 PM, Bhupesh Sharma wrote:
On Thu, Jan 10, 2019 at 6:28 PM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 14:59, Bhupesh Sharma 写道:
Hi Kazu, Lianbo,
On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote: > > 在 2019年01月10日 04:38, Kazuhito Hagio 写道: >> If a crash occurs repeatedly after enabling kdump, the system goes >> into a crash loop and the dump target may get filled up by vmcores. >> This is likely to happen especially with early kdump. >> >> This patch introduces 'final_action' option to kdump.conf, in order >> for users to be able to power off the system even after capturing >> a vmcore successfully. >> >> Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com >> Cc: Dave Young dyoung@redhat.com >> Cc: Lianbo Jiang lijiang@redhat.com >> --- >> kdump-lib-initramfs.sh | 13 +++++++++++++ >> kdump.conf | 5 +++++ >> kdump.conf.5 | 6 ++++++ >> kdumpctl | 22 +++++++++++++++++++++- >> 4 files changed, 45 insertions(+), 1 deletion(-) >> >> diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh >> index f5155a4..9f482cd 100755 >> --- a/kdump-lib-initramfs.sh >> +++ b/kdump-lib-initramfs.sh >> @@ -70,6 +70,19 @@ get_kdump_confs() >> ;; >> esac >> ;; >> + final_action) >> + case $config_val in >> + reboot) >> + FINAL_ACTION="systemctl reboot -f" >> + ;; >> + halt) >> + FINAL_ACTION="halt" >> + ;; >> + poweroff) >> + FINAL_ACTION="systemctl poweroff -f" >> + ;; >> + esac >> + ;; >> esac >> done < $KDUMP_CONF >> > Thanks for your patch. > > Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls > the do_default_action() first, and then executes the final action. Because the default is always > 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no > chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together.
Indeed.
Yes, this is why I wrote the following in the 2/2 patch.
final_action poweroffdefault poweroff> Not sure whether it would be more better like this: > > diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh > index 7ba99b6..953b8bc 100755 > --- a/kdump-lib-initramfs.sh > +++ b/kdump-lib-initramfs.sh > @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" > CORE_COLLECTOR="" > DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" > DMESG_COLLECTOR="/sbin/vmcore-dmesg" > -DEFAULT_ACTION="systemctl reboot -f" > +DEFAULT_ACTION="" > > do_default_action() > { > - echo "Kdump: Executing default action $DEFAULT_ACTION" > - eval $DEFAULT_ACTION > + if [ "$DEFAULT_ACTION" == "" ]; then > + echo "Kdump: default action is not set." > + else > + echo "Kdump: Executing default action $DEFAULT_ACTION" > + eval $DEFAULT_ACTION > + fi > } > > It makes sure that the final action can be called in case user doesn't set the 'default poweroff' > and dumping failure.
Perhaps its only me but I find using two terms - 'default action' and 'final action' confusing when used together. Shouldn't the default action be practically the final action in normal cases?
I understand that perhaps this is useful for early dump, but in that case shouldn't we be making the default action as power-off instead.
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Yes, but we shouldn't change the default value of 'default' option because many users would be confused by the change.
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
I also think the current terms are confusing and something like 'success_action' and 'failure_action' might be more intuitive.
So an idea I thought of is adding 'failure_action' as an alias of 'default' and removing 'default' in the future.
failure_action <reboot | halt | poweroff | shell | dump_to_rootfs> default <reboot | halt | poweroff | shell | dump_to_rootfs> - Action to perform in case dumping fails. No difference between "failure_action" and "default" but "default" directive will be removed in the future.
Sounds good, also should check these two can not coexist in kdump.conf
success_action <reboot | halt | poweroff> - Action to perform in case dumping succeeds.
succes_action is not very accurate, in case kdump failed "default" action runs, and after that final action still get change to run.
So final_action seems better.
As I mentioned before, from a english reader p-o-v, default action implies 'the final preselected action in case no alternative is specified by the user or programmer'. Rather lets consider failsafe_action. By the english dictionary it means 'a system or plan that comes into operation in the event of something going wrong or that is in place to prevent such an occurrence.'
So in case kdump fails default action runs and after that failsafe action runs.
I'm confused, are you suggesting still keep "default" untouched and move final action to "failsafe". If so I think it will cause more confusion.
faiure_action then final_action looks good enough.
As for "default" in the future it can be applied to any of above but not explictily called "default". eg. "default failure action" "default final_action" which can be documented. But in config file we just not use the word "default"
"default" option need still exist now because a lot of users have used it for long time.
Thanks, Bhupesh
Any other ideas?
Thanks, Kazu _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Thanks Dave
Thanks Dave
On Mon, Jan 14, 2019 at 8:00 AM Dave Young dyoung@redhat.com wrote:
On 01/13/19 at 04:59pm, Bhupesh Sharma wrote:
Hi Dave,
On Fri, Jan 11, 2019 at 2:13 PM Dave Young dyoung@redhat.com wrote:
Hi Kazu,
On 01/10/19 at 04:41pm, Kazuhito Hagio wrote:
Hi Lianbo, Bhupesh
Thank you for the comments.
On 1/10/2019 2:40 PM, Bhupesh Sharma wrote:
On Thu, Jan 10, 2019 at 6:28 PM lijiang lijiang@redhat.com wrote:
在 2019年01月10日 14:59, Bhupesh Sharma 写道: > Hi Kazu, Lianbo, > > On Thu, Jan 10, 2019 at 10:00 AM lijiang lijiang@redhat.com wrote: >> >> 在 2019年01月10日 04:38, Kazuhito Hagio 写道: >>> If a crash occurs repeatedly after enabling kdump, the system goes >>> into a crash loop and the dump target may get filled up by vmcores. >>> This is likely to happen especially with early kdump. >>> >>> This patch introduces 'final_action' option to kdump.conf, in order >>> for users to be able to power off the system even after capturing >>> a vmcore successfully. >>> >>> Signed-off-by: Kazuhito Hagio k-hagio@ab.jp.nec.com >>> Cc: Dave Young dyoung@redhat.com >>> Cc: Lianbo Jiang lijiang@redhat.com >>> --- >>> kdump-lib-initramfs.sh | 13 +++++++++++++ >>> kdump.conf | 5 +++++ >>> kdump.conf.5 | 6 ++++++ >>> kdumpctl | 22 +++++++++++++++++++++- >>> 4 files changed, 45 insertions(+), 1 deletion(-) >>> >>> diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh >>> index f5155a4..9f482cd 100755 >>> --- a/kdump-lib-initramfs.sh >>> +++ b/kdump-lib-initramfs.sh >>> @@ -70,6 +70,19 @@ get_kdump_confs() >>> ;; >>> esac >>> ;; >>> + final_action) >>> + case $config_val in >>> + reboot) >>> + FINAL_ACTION="systemctl reboot -f" >>> + ;; >>> + halt) >>> + FINAL_ACTION="halt" >>> + ;; >>> + poweroff) >>> + FINAL_ACTION="systemctl poweroff -f" >>> + ;; >>> + esac >>> + ;; >>> esac >>> done < $KDUMP_CONF >>> >> Thanks for your patch. >> >> Once dumping fails, it will switch to the kdump-error-handler.sh, but this script always calls >> the do_default_action() first, and then executes the final action. Because the default is always >> 'reboot' in case the 'default' is not set in '/etc/kdump.conf', so the final action could have no >> chance to execute. Unless we set 'default poweroff' and 'final_action poweroff' together. > > Indeed.
Yes, this is why I wrote the following in the 2/2 patch.
final_action poweroffdefault poweroff> >> Not sure whether it would be more better like this: >> >> diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh >> index 7ba99b6..953b8bc 100755 >> --- a/kdump-lib-initramfs.sh >> +++ b/kdump-lib-initramfs.sh >> @@ -6,7 +6,7 @@ KDUMP_PATH="/var/crash" >> CORE_COLLECTOR="" >> DEFAULT_CORE_COLLECTOR="makedumpfile -l --message-level 1 -d 31" >> DMESG_COLLECTOR="/sbin/vmcore-dmesg" >> -DEFAULT_ACTION="systemctl reboot -f" >> +DEFAULT_ACTION="" >> >> do_default_action() >> { >> - echo "Kdump: Executing default action $DEFAULT_ACTION" >> - eval $DEFAULT_ACTION >> + if [ "$DEFAULT_ACTION" == "" ]; then >> + echo "Kdump: default action is not set." >> + else >> + echo "Kdump: Executing default action $DEFAULT_ACTION" >> + eval $DEFAULT_ACTION >> + fi >> } >> >> It makes sure that the final action can be called in case user doesn't set the 'default poweroff' >> and dumping failure. > > Perhaps its only me but I find using two terms - 'default action' and > 'final action' confusing when used together. > Shouldn't the default action be practically the final action in normal cases? > > I understand that perhaps this is useful for early dump, but in that > case shouldn't we be making the default action as power-off instead. >
Normal kdump could face the same problem(crash loop), the 'poweroff' option would still make sense for normal kdump.
Yes, but we shouldn't change the default value of 'default' option because many users would be confused by the change.
Use a convention like 'failsafe_action' then instead of 'final_action' which is confusing when used in conjunction with 'default_action'.
I also think the current terms are confusing and something like 'success_action' and 'failure_action' might be more intuitive.
So an idea I thought of is adding 'failure_action' as an alias of 'default' and removing 'default' in the future.
failure_action <reboot | halt | poweroff | shell | dump_to_rootfs> default <reboot | halt | poweroff | shell | dump_to_rootfs> - Action to perform in case dumping fails. No difference between "failure_action" and "default" but "default" directive will be removed in the future.
Sounds good, also should check these two can not coexist in kdump.conf
success_action <reboot | halt | poweroff> - Action to perform in case dumping succeeds.
succes_action is not very accurate, in case kdump failed "default" action runs, and after that final action still get change to run.
So final_action seems better.
As I mentioned before, from a english reader p-o-v, default action implies 'the final preselected action in case no alternative is specified by the user or programmer'. Rather lets consider failsafe_action. By the english dictionary it means 'a system or plan that comes into operation in the event of something going wrong or that is in place to prevent such an occurrence.'
So in case kdump fails default action runs and after that failsafe action runs.
I'm confused, are you suggesting still keep "default" untouched and move final action to "failsafe".
That's correct.
If so I think it will cause more confusion.
I am not sure I understand the concern, but I just pasted the meanings from the dictionary. I still believe the terms I suggested are easier to understand when used together.
But I am fine if you and Kazu have other thoughts.
Thanks, Bhupesh
faiure_action then final_action looks good enough.
As for "default" in the future it can be applied to any of above but not explictily called "default". eg. "default failure action" "default final_action" which can be documented. But in config file we just not use the word "default"
"default" option need still exist now because a lot of users have used it for long time.
Thanks, Bhupesh
Any other ideas?
Thanks, Kazu _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Thanks Dave
Thanks Dave
Hi Bhupesh,
I am not sure I understand the concern, but I just pasted the meanings from the dictionary. I still believe the terms I suggested are easier to understand when used together.
The logic is below:
1. kdump succeeded --> final_action 2. kdump failed --> default (failure_acion) --> final_action
So in either cases if change final_action to "failsafe" it will be odd. final_action is just the final action without considering previous results succeeded or not
Thanks Dave
On 01/14/19 at 01:29pm, Dave Young wrote:
Hi Bhupesh,
I am not sure I understand the concern, but I just pasted the meanings from the dictionary. I still believe the terms I suggested are easier to understand when used together.
The logic is below:
- kdump succeeded --> final_action
- kdump failed --> default (failure_acion) --> final_action
So in either cases if change final_action to "failsafe" it will be odd. final_action is just the final action without considering previous results succeeded or not
Unless default action is reboot, halt, or shutdown that is choosed by user.
Thanks Dave
On 01/14/19 at 01:35pm, Dave Young wrote:
On 01/14/19 at 01:29pm, Dave Young wrote:
Hi Bhupesh,
I am not sure I understand the concern, but I just pasted the meanings from the dictionary. I still believe the terms I suggested are easier to understand when used together.
The logic is below:
- kdump succeeded --> final_action
- kdump failed --> default (failure_acion) --> final_action
So in either cases if change final_action to "failsafe" it will be odd. final_action is just the final action without considering previous results succeeded or not
Unless default action is reboot, halt, or shutdown that is choosed by user.
It seems good to say above in the description of final_action to make it clear to user though.
Thanks Dave
On 1/14/2019 12:47 AM, Dave Young wrote:
On 01/14/19 at 01:35pm, Dave Young wrote:
On 01/14/19 at 01:29pm, Dave Young wrote:
Hi Bhupesh,
I am not sure I understand the concern, but I just pasted the meanings from the dictionary. I still believe the terms I suggested are easier to understand when used together.
The logic is below:
- kdump succeeded --> final_action
- kdump failed --> default (failure_acion) --> final_action
So in either cases if change final_action to "failsafe" it will be odd. final_action is just the final action without considering previous results succeeded or not
Unless default action is reboot, halt, or shutdown that is choosed by user.
It seems good to say above in the description of final_action to make it clear to user though.
Agreed. I'll add this as well.
Thanks, Kazu
-
Bhupesh Sharma -
Dave Young -
Kazuhito Hagio -
lijiang