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