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(a)ab.jp.nec.com&gt; Cc: Dave Young <dyoung(a)redhat.com&gt; Cc: Lianbo Jiang <lijiang(a)redhat.com&gt; --- 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. -- 2.18.0

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(a)ab.jp.nec.com&gt; Cc: Dave Young <dyoung(a)redhat.com&gt; Cc: Lianbo Jiang <lijiang(a)redhat.com&gt; --- 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

Hi Kazu, Lianbo, On Thu, Jan 10, 2019 at 10:00 AM lijiang <lijiang(a)redhat.com&gt; 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(a)ab.jp.nec.com&gt; >> Cc: Dave Young <dyoung(a)redhat.com&gt; >> Cc: Lianbo Jiang <lijiang(a)redhat.com&gt; >> --- >> 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. > 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.

On Thu, Jan 10, 2019 at 6:28 PM lijiang <lijiang(a)redhat.com&gt; wrote: > > 在 2019年01月10日 14:59, Bhupesh Sharma 写道: >> Hi Kazu, Lianbo, >> >> On Thu, Jan 10, 2019 at 10:00 AM lijiang <lijiang(a)redhat.com&gt; 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(a)ab.jp.nec.com&gt; >>>> Cc: Dave Young <dyoung(a)redhat.com&gt; >>>> Cc: Lianbo Jiang <lijiang(a)redhat.com&gt; >>>> --- >>>> 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.

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

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(a)redhat.com&gt; wrote: >> >> 在 2019年01月10日 14:59, Bhupesh Sharma 写道: >>> Hi Kazu, Lianbo, >>> >>> On Thu, Jan 10, 2019 at 10:00 AM lijiang <lijiang(a)redhat.com&gt; 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(a)ab.jp.nec.com&gt; >>>>> Cc: Dave Young <dyoung(a)redhat.com&gt; >>>>> Cc: Lianbo Jiang <lijiang(a)redhat.com&gt; >>>>> --- >>>>> 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 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 _______________________________________________ kexec mailing list -- kexec(a)lists.fedoraproject.org To unsubscribe send an email to kexec-leave(a)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 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(a)redhat.com&gt; wrote: > >> > >> 在 2019年01月10日 14:59, Bhupesh Sharma 写道: > >>> Hi Kazu, Lianbo, > >>> > >>> On Thu, Jan 10, 2019 at 10:00 AM lijiang <lijiang(a)redhat.com&gt; 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(a)ab.jp.nec.com&gt; > >>>>> Cc: Dave Young <dyoung(a)redhat.com&gt; > >>>>> Cc: Lianbo Jiang <lijiang(a)redhat.com&gt; > >>>>> --- > >>>>> 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 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. 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.

On 01/13/19 at 04:59pm, Bhupesh Sharma wrote: > Hi Dave, > > On Fri, Jan 11, 2019 at 2:13 PM Dave Young <dyoung(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > > > >> > > > >> 在 2019年01月10日 14:59, Bhupesh Sharma 写道: > > > >>> Hi Kazu, Lianbo, > > > >>> > > > >>> On Thu, Jan 10, 2019 at 10:00 AM lijiang <lijiang(a)redhat.com&gt; 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(a)ab.jp.nec.com&gt; > > > >>>>> Cc: Dave Young <dyoung(a)redhat.com&gt; > > > >>>>> Cc: Lianbo Jiang <lijiang(a)redhat.com&gt; > > > >>>>> --- > > > >>>>> 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 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. > > > > 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.