On 04/10/2012 03:09 PM, Vivek Goyal wrote:
On Tue, Apr 10, 2012 at 11:17:37AM +0200, Michal Toman wrote:
On 2012/10/04 09:48, Cong Wang wrote:
On 04/09/2012 05:32 PM, Dave Young wrote:
On 04/09/2012 04:55 PM, Nikola Pajkovsky wrote:
> From kdump side of view, the vmcore should be there instead of being
deleted, It's the default behaviour. Could the abrt keep them?
I can not think out why it will delete them if user/customer intend to
capture and save them vmcore there.
Me neither. vmcore should be stored for further kernel debugging.
From kdump side of view nothing changes. It really writes the vmcore
to /var/crash.
The "disappearing" happens after reboot, when abrt-vmcore service
processes it. The vmcore itself is not deleted, but moved to
/var/spool/abrt/vmcore-{whatever}/vmcore so that it can be processed
like any other ABRT problem. You can still access it there, nothing
is lost. In addition, ABRT provides tools to automatically install
appropriate kernel debuginfo, extract the oops message and report it
to Bugzilla.
If you still want the old behavior, you can simply disable the
abrt-vmcore service and ABRT will not touch the vmcore at all.
I think vmcore should not be moved by ABRT. At max they can create
a soft link to vmcore present in /var/crash.
- yes, we're going to teach it to use links
(https://fedorahosted.org/abrt/ticket/448)
I am surprised that abrt guys did not even communicate this decision
to kdump folks and just went ahead and decided to automatically move
vmcore.
- I'm not sure how this affects the kdump devs. We let kdump to du it's
work and then just "steal" the results (which is wrong I agree, but
doesn't have anything to do with kdump devs..)
In rhel history kernel vmcore has always been present in /var/crash
by default. Kdump allows user to change the location and save it either
in a different directory, different filesystem or on a different machine
over network etc. So first of all assuming that after system crash
vmcore is present in /var/crash is broken.
- yes, it shouldn't be hardcoded, we can read the kdump config
Secondly, user might have mounted a separate disk on /var/crash
which has sufficient space to store vmcores. Trying to move it to /
var/spool/ might fail due to lack of space.
- yes, that's why we should use the links
Thirdly, it breaks the existing behavior. So abrt maintainers, please
change this behavior. Don't break thinkgs by default. I think hardcoding
the logic to look into /var/crash/ for vmcores or creating a soft
link should work for you. Even if does not work for whatever reason,
please disable abrt-vmcore service by default. This is completely
unexpected change of behavior.
- "breaks the behavior" is a bit too hard, it doesn't break things. The
only think it could break is some app which expects the vmcores in the
kdump directory, but I don't know about such app in Fedora (maybe I just
wasn't looking hard enough)
Sorry for the troubles, we will fix it with next update (either fix the
abrt vmcore plugin or disable the service if we wouldn't make it for F17)
Have a nice day,
Jirka
Thanks
Vivek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
