From owner-svn-src-all@FreeBSD.ORG Thu Sep 10 16:57:10 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DECE11065670; Thu, 10 Sep 2009 16:57:10 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from websrv01.jr-hosting.nl (websrv01.jr-hosting.nl [78.47.69.233]) by mx1.freebsd.org (Postfix) with ESMTP id 934048FC17; Thu, 10 Sep 2009 16:57:10 +0000 (UTC) Received: from a83-163-38-147.adsl.xs4all.nl ([83.163.38.147] helo=[10.0.2.66]) by websrv01.jr-hosting.nl with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlmxJ-0001T4-4P; Thu, 10 Sep 2009 18:57:09 +0200 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Remko Lodder In-Reply-To: Date: Thu, 10 Sep 2009 18:57:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <200909101404.n8AE41C6021588@svn.freebsd.org> <200909101023.44913.jhb@freebsd.org> <1252593149.75144.18.camel@bauer.cse.buffalo.edu> <200909101118.22525.jhb@freebsd.org> To: Robert Watson X-Mailer: Apple Mail (2.1075.2) Cc: src-committers@freebsd.org, John Baldwin , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-8@freebsd.org, Ken Smith , Ken Smith Subject: Re: 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 16:57:11 -0000 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