From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 22 01:54:26 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 798C81065674 for ; Sat, 22 Nov 2008 01:54:26 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 298978FC08 for ; Sat, 22 Nov 2008 01:54:26 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1167207rvf.43 for ; Fri, 21 Nov 2008 17:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=AsXdT8q04Ap/5cNTnIuX4X4k2/Aru5MbztXX7l5VwY4=; b=Up79uEEPFLNIlp7/pBH5fbZJT5sfxR6Nfp17l8Hm6+lk1ClBLQVexai/QJ69Qc2I5f l1oELbBHfWickOP5GBIrtVQRj+tuWFFRjl4fNU7ZbTwmRiwjSdUt0PcAG5z/Yjmf9VoM +SFSFRDQHnk9omc3OHcSWWCkyxXD/DEFLU1DI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Nj94ermIIYkj93iEQXRTSHZdp3ZLE2VMebcu7FPpD1VfkNApOUlNqz5Iig/EVpYb8H djL3/93svMQg1hMyzF7ndOFItIPn4C73KYOgrYVz1bb9JhKyJV//MX3REyxwJLZ/2BgJ ssYUA1MS+dA8L+zibt6e2hgSsXMlckYckjyF4= Received: by 10.141.29.14 with SMTP id g14mr617318rvj.150.1227318865550; Fri, 21 Nov 2008 17:54:25 -0800 (PST) Received: by 10.141.79.14 with HTTP; Fri, 21 Nov 2008 17:54:25 -0800 (PST) Message-ID: <7d6fde3d0811211754s220cc980l1a43109155c7013f@mail.gmail.com> Date: Fri, 21 Nov 2008 17:54:25 -0800 From: "Garrett Cooper" To: "Freddie Cash" In-Reply-To: <200811200831.47062.fjwcash@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081120100314.GA22639@icarus.home.lan> <200811200831.47062.fjwcash@gmail.com> Cc: freebsd-hackers@freebsd.org 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: Sat, 22 Nov 2008 01:54:26 -0000 On Thu, Nov 20, 2008 at 8:31 AM, Freddie Cash wrote: > 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 [gcooper@optimus ~]$ grep -rs dmesg.boot /usr/src/ /usr/src/contrib/ntp/scripts/freq_adj.in: open(DM, "/var/run/dmesg.boot"); /usr/src/etc/defaults/rc.conf:dmesg_enable="YES" # Save dmesg(8) to /var/run/dmesg.boot /usr/src/etc/rc.d/dmesg:dmesg_file="/var/run/dmesg.boot" /usr/src/sbin/dmesg/dmesg.8:.Bl -tag -width ".Pa /var/run/dmesg.boot" -compact /usr/src/sbin/dmesg/dmesg.8:.It Pa /var/run/dmesg.boot [gcooper@optimus ~]$ /etc/rc.d/dmesg does this. -Garrett