On Mon, Jan 14, 2019 at 8:00 AM Dave Young <dyoung(a)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(a)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(a)redhat.com>
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> 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>
> > > >>>>> Cc: Dave Young <dyoung(a)redhat.com>
> > > >>>>> Cc: Lianbo Jiang <lijiang(a)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 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".
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(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
> > >
> > > Thanks
> > > Dave
>
> Thanks
> Dave