From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 20 10:03:15 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 CAAF51065670 for ; Thu, 20 Nov 2008 10:03:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id ABABD8FC16 for ; Thu, 20 Nov 2008 10:03:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id hN2U1a00117UAYkA6N3FrX; Thu, 20 Nov 2008 10:03:15 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id hN3E1a0062P6wsM8ZN3Fr4; Thu, 20 Nov 2008 10:03:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=NTqVaNuko5sA:10 a=QycZ5dHgAAAA:8 a=HZahj6u9mvrA2wFbLdIA:9 a=-nwF6JlQsMgHF_aUBBwA:7 a=qZ4zffk0aSq9YKyGt1g3O94mfPIA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id AA4B733C1C; Thu, 20 Nov 2008 02:03:14 -0800 (PST) Date: Thu, 20 Nov 2008 02:03:14 -0800 From: Jeremy Chadwick To: Nate Eldredge Message-ID: <20081120100314.GA22639@icarus.home.lan> References: <20081028081154.GQ6808@hoeg.nl> <20081118213410.GA81783@hoeg.nl> <20081118214919.GM83287@bunrab.catwhisker.org> <7d6fde3d0811190202p4f6d8941h3932b70b8fe1a93a@mail.gmail.com> <20081119104731.GA83366@icarus.home.lan> <20081120063936.GU51761@server.vk2pj.dyndns.org> <20081120070820.GA19307@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Hackers 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 10:03:15 -0000 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. 2) I don't understand how this would work (meaning, technically and literally: I do not understand). How do messages like "CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU)" get written to syslog when syslogd isn't even running (or any filesystems) mounted at that time? There must be some magic involved there (since syslog == libc, not syscall) when syslogd starts, but I don't know how it works. > This way the buffer is cleared before any unprivileged users get to do > anything. No kernel changes needed, just a little tweaking of the init > scripts at most. > > If you should have a crash and suspect there is useful data in the > buffer, you can boot to single-user mode (avoiding the clear) and > retrieve it manually. > > Seems like this should make everyone happy. What I'm not understanding is the resistance towards Rink's patch, assuming the tunable defaults to disabled/off. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |