svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf

[Remko Lodder]

On Sep 10, 2009, at 5:43 PM, Robert Watson wrote:

>
> On Thu, 10 Sep 2009, John Baldwin wrote:
>
>>> It has been pointed out to me on the mailing lists that leaving it  
>>> on for stable/7 was an oversight, it is off on previous branches.
>>>
>>> I can understand the motivation for it.  In a data center full of  
>>> production machines crash dumps cause reboots to take longer and  
>>> potentially cause disk space issues.  In those sorts of  
>>> environments it's best if by *default* the crash dumps don't  
>>> happen and if an admin finds they need it they turn it on.
>>>
>>> This is one of those "There is no right answer" things...
>>
>> Hmm, I thought the crashdumps were a conscious descision as part of  
>> another change in 7.x (shipping with debug symbols enabled by  
>> default) to try to make it easier to get more useful crash reports  
>> from stock kernels.  Having the debug symbols present is probably  
>> enough for that though since it is fairly easy to enable crashdumps  
>> in rc.conf vs. having to build a new kernel just to get debug  
>> symbols.  Should we change the default behavior in 7?
>
> I wonder if we could teach libkvm how to work directly from a  
> crashdump in situ in the swap partition?  This would not fix "slower  
> reboot times" but it would help a lot with the "running out of disk  
> space" thing.  I see no reason at all we shouldn't be logging things  
> like panics/stack traces for every crash in our normal logs -- in  
> fact, that was much of the motivation for text dumps (and crashinfo  
> too, no doubt): capture critical crash information in a compact way  
> that can be e-maile around, etc, without the overhead of multi-gig  
> dumps. Teaching libkvm how to work on crash dump partitions would  
> let us avoid having the crashdump reside in the file system and help  
> a lot with that problem.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge

I agree with that; it would (!) help the bugbusting team in gathering  
required information. If there is an way to automate crashdumps and  
proper reporting and stick that in /var/crash/crash.$date or something  
and tell people that
they can report their problems on the bugs list where needed, we have  
information upfront. I still remember the time where we had to chase  
people to get this information, sometimes never being able to properly  
get the information.
If it is there by default, it will help.

Please consider keeping it enabled..

Thanks,
Remko