From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 20 17:00:11 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F951065673 for ; Thu, 20 Nov 2008 17:00:11 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 52AD08FC19 for ; Thu, 20 Nov 2008 17:00:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 665621A000B0C for ; Thu, 20 Nov 2008 08:31:49 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CkPFgl8zIa0M for ; Thu, 20 Nov 2008 08:31:47 -0800 (PST) Received: from coal (unknown [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 2C1C91A000B3E for ; Thu, 20 Nov 2008 08:31:47 -0800 (PST) From: Freddie Cash To: freebsd-hackers@freebsd.org Date: Thu, 20 Nov 2008 08:31:46 -0800 User-Agent: KMail/1.9.9 References: <20081120100314.GA22639@icarus.home.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811200831.47062.fjwcash@gmail.com> Subject: Re: [Testers wanted] /dev/console cleanups X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 17:00:11 -0000 On November 20, 2008 02:42 am Nate Eldredge wrote: > On Thu, 20 Nov 2008, Jeremy Chadwick wrote: > > On Wed, Nov 19, 2008 at 11:48:36PM -0800, Nate Eldredge wrote: > >> On Wed, 19 Nov 2008, Jeremy Chadwick wrote: > >>> On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: > >>>> I hope that never gets committed - it will make debugging kernel > >>>> problems much harder. There is already a kern.msgbuf_clear sysctl > >>>> and maybe people who are concerned about msgbuf leakage need to > >>>> learn to use it. > >>> > >>> And this sysctl is only usable *after* the kernel loads, which > >>> means you lose all of the messages shown from the time the kernel > >>> loads to the time the sysctl is set (e.g. hardware > >>> detected/configured). This is even less acceptable, IMHO. > >> > >> But surely you can arrange that the contents are written out to > >> /var/log/messages first? > >> > >> E.g. a sequence like > >> > >> - mount /var > >> - write buffer contents via syslogd > >> - clear buffer via sysctl > >> - allow user logins > > > > This has two problems, but I'm probably missing something: > > > > 1) See my original post, re: users of our systems use "dmesg" to find > > out what the status of the system is. By "status" I don't mean "from > > the point the kernel finished to now", I literally mean they *expect* > > to see the kernel device messages and all that jazz. No, I'm not > > making this up, nor am I arguing just to hear myself talk (despite > > popular belief). I can bring these users into the discussion if > > people feel it would be useful. > > I forgot about that point. I can sympathize with those users; I > feel the same way. It's a good way to learn about a system as a > mere user (since usually sysadmins don't remember or bother to > disable it). > > However, in my experience dmesg isn't really the best thing for that > purpose; the kernel message buffer tends to get wiped out once the > system has been up for a while. (It fills with ipfw logs, ethernet > link state changes, etc.) > > Maybe a better approach would be to point them to /var/log/messages > or whichever log file stores them permanently. I think what you are looking for is /var/run/dmesg.boot, which stores just the dmesg info from the initial boot. Nothing gets logged to this after the boot is complete. This file has been a life saver quite a few times since I discovered it, and is something I really miss when working with mis-behaving Linux systems. -- Freddie Cash fjwcash@gmail.com