This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1258652 - RFE: Add an option to kdump.conf to change the action taken after successfully saving a vmcore
RFE: Add an option to kdump.conf to change the action taken after successfull...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kexec-tools (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: kdump team
Qiao Zhao
: FutureFeature
Depends On:
Blocks: 1203710 1295826 1296180 1313485
  Show dependency treegraph
Reported: 2015-08-31 18:52 EDT by
Modified: 2017-08-30 01:23 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-11 21:20:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description 2015-08-31 18:52:25 EDT
Add an option to kdump.conf to change the action taken after successfully saving a vmcore file.  Currently the kdump.conf "default" directive allows the administrator to choose an action to take if kdump fails to save a vmcore.  If a vmcore is successfully saved there is no similar option and the system performs a reboot.  Customer requests a new kdump.conf directive to specify the action to take after a vmcore file is successfully saved.  Similar to the "default" directive it should allow reboot, halt, poweroff.  The current workaround is to use:

        "kdump_post /sbin/shutdown"   (or specify an admin-created script)

to power-off the system after saving a vmcore.
Comment 4 Dave Young 2016-04-18 23:28:07 EDT

kdump_post is designed for such purpose, one can write a script to check the return value (the first argument) for dumping status.

We tend not to add new options to kdump.conf, could you use the workaround for the use case?

Comment 5 Carsten Grohmann 2016-05-09 06:57:16 EDT
Hi Dave,

I'm answering your question because I've requested this change via HPE last year. 

I'm a Unix admin and my question is: Is kdump an application or a framework?

If it's a framework, you can drop most of existing features because you can handle all those steps in customer scripts and use "kdump_pre" resp. "kdump_post" to run these scripts.

If it's an application, you should implement an option to control the behaviour after vmcore has saved successfully.

I see kdump as an application. Thereby I ask you to implement this RFE.

Comment 6 Dave Young 2016-05-09 21:10:41 EDT
Hi, Carsten

Kdump contains several different parts including kernel and userspace tools, it  it can be regarded as an application, but we also allow user to specify their own scripts to handle issues we do not support by default. 

Kdump scripts take care of all kinds of things in 2nd kernel based on all kinds of different setup in 1st kernel, it is rather complicated, we would like less bugs, easier to maintain, and more reliable for one to collect vmcores so we need balance these things.

In this case I think let user to do it is a better choice because we have provided the kdump_post functionality.  The "default" action in /etc/kdump.conf is introduced for only vmcore saving failure cases, it has been there from the very beginning, adding another default action for different purpose seems not a good choice. Thus I would like user to do it instead of introduce the new option.

Comment 7 Carsten Grohmann 2016-05-10 09:02:37 EDT
Hi Dave,

we use the suggested workaround already. Finally you are the application owner and you can decide about development direction.

Your argumentation within this topic is the direct opposite to systemd. There eliminates all shell scripts.

I'm the user and the simple script increased the complexity as well as additional dependencies of my kdump configuration. Thereby a simple configurable action for success would be a real be benefit. The most code for the new option is probably already written as code for the default option.

I still kindly ask to to implement this option. Additionally I'd suggest renaming of the "default" option to "onfailure". I always associate a default action with success, but never with a failure. Maybe the renaming is a option for a later release.

Comment 8 Dave Young 2016-05-10 22:38:28 EDT
Hi, Carsten

Thanks for your understanding.

I do not know if it is proper to compare with systemd, for your case I think
"kdump_post /sbin/shutdown" is simple enough without extra scripts needed?

I agree that your suggestion about "onfailure" and "default" sounds better then current name. Problem is "default" has been used for long time from the very beginning so that I'm afraid it is hard to change, it will break customer old configuration, they will still assume original meanings.

Comment 9 Carsten Grohmann 2016-05-11 06:42:29 EDT
Hi David,

Thank you for the discussion. You may close this RFE.

Kind regards,
Comment 10 Dave Young 2016-05-11 21:20:06 EDT
Hi, Carsten

Ok, thanks a lot. Let's keep it in mind, when there are strong reasons in the future we can reopen and discuss it again.


Note You need to log in before you can comment on or make changes to this bug.