Bug 1258652
| Summary: | RFE: Add an option to kdump.conf to change the action taken after successfully saving a vmcore | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | nyelle <nyelle> |
| Component: | kexec-tools | Assignee: | kdump team <kdump-team-bugs> |
| Status: | CLOSED WONTFIX | QA Contact: | Qiao Zhao <qzhao> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | carsten.grohmann, ccui, kcleveng, nyelle, ruyang |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-05-12 01:20:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1203710, 1295826, 1296180, 1313485 | ||
Hi, 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? Thanks Dave 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. Regards, Carsten 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. Thanks Dave 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. Regards, Carsten 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. Thanks Dave Hi David, Thank you for the discussion. You may close this RFE. Kind regards, Carsten 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. Dave |
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.