On Thu, Nov 20, 2008 at 8:31 AM, Freddie Cash <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]

[EMAIL PROTECTED] ~]$ 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
[EMAIL PROTECTED] ~]$

/etc/rc.d/dmesg does this.

-Garrett
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to