Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Nov 2008 08:31:46 -0800
From:      Freddie Cash <fjwcash@gmail.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: [Testers wanted] /dev/console cleanups
Message-ID:  <200811200831.47062.fjwcash@gmail.com>
In-Reply-To: <Pine.GSO.4.64.0811200219390.1597@zeno.ucsd.edu>
References:  <e71790db0810271936r1ce4619an1d64c6aae62c3ec1@mail.gmail.com> <20081120100314.GA22639@icarus.home.lan> <Pine.GSO.4.64.0811200219390.1597@zeno.ucsd.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811200831.47062.fjwcash>