On Tue, 20 Mar 2001, Thomas Moestl wrote:
Hello Thomas,
> > Why it is here normal on one machine and cutted on the other?
> > And why does it work before ( I'm sure in December it doesn't work like
> > now )?
>
> OK, I'll go into details a little more. Not too long ago, a patch was
> MFCed that allows logging console output. To allow this, this ouput is
> written into the kernel message buffer, where it can be picked up by
> syslog using the /dev/klog interface. Normal kernel output is written
> to the message buffer as is, while console output is prefixed with a
> string in the form "<category>", where category is a number (118 in
> this case, LOG_CONSOLE|LOG_INFO). dmesg will ignore messages that
> start with such a string indicating that the message didn't come from
> the kernel unless it is invoked with the -a option. If syslogd is
> configured to echo some messages to the console, those messages will
> be appended to the kernel message buffer, and if this happens too
> often, this will overwrite all the kernel messages. A common situation
> is that a lot of kernel messages are generated that fill up the message
> buffer, syslog snarfs those a little later, writes them to the console
> and thus overwrites the original kernel messages in turn. dmesg
> will show nothing in this case, or, more often, a line that came from
> the console, but of which the first character(s) were overwritten by a
> new message (they don't start with a "<number>" magic string then, and
> dmesg will print them).
> So, dmesg will work as expected on machines that didn't generate
> enough messages yet, or on systems from before the MFC.
Thanks for this long explanation.
Maybe the daily "security check output" will be correct:
host.domain.de kernel log messages:
> ia tun0
Again. Thanks for your answers.
--
Noch einen schoenen Tag
Noel
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
