/var/crash/* disappear after reboot

Jiri Moskovcak jmoskovc at redhat.com
Wed Apr 11 07:20:07 UTC 2012


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



More information about the devel mailing list