[Techtalk] Hiding/redirecting console messages

[Val Henson]

On Sun, Jul 21, 2002 at 07:13:35AM +1000, Dana Sibera wrote:
> I have a mac Quadra 605 running debian - just ran through a bunch of 
> upgrades to Woody, but still running the 2.2.19 kernel for now.

First, let me just say that you're cool.

> There's a curiosity in the 68k kernel (seems to be only mac68ks, but I 
> could be wrong) where with the Sonic-powered ethernet cards, there's the 
> occasional message put to console that says "Unexpected IRQ 3 on device 
> 00000000" - it could be 30 seconds or several minutes between 
> occurences, though it'd always appear about 3-5 times on booting. This 
> has never been a problem - it seems to be just One Of Those Things I get 
> from running a 68k mac with sonic ethernet & linux, and it -used- to 
> only occur when the machine was booting, then stop after a console login 
> prompt appeared.
> 
> Now the message is throwing itself around the console, even after boot. 
> Once again it's all -working- fine, and has been (and is still) serving 
> danamania.com fine for 3 months now, but it's just horrifically 
> annoying!. Are there options anywhere to redirect messages like this one 
> to a logfile, and keep them off the console?. Perhaps even throw that 
> particular one away :P.
> 
> I've peeked into /etc/syslog.conf and found nothing turned on there 
> directing messages to console or ttys. The message does get directed to 
> /var/log/syslog and /var/log/kern.log.

What you're looking for is klogd.  The man page will tell most of what
you need to know ("man klogd" for our listeners) but to prevent -all-
kernel messages from going to the console, you would edit (or create)
/etc/conf/syslog and add a line like so:

KLOGD_OPTIONS="-2 -c 0"

The "-c 0" says "Only allow kernel messages with a level lower than 0
to be printed to the console."  Since no messages have a level lower
than 0, after /etc/rc.d/init.d/syslog runs, no kernel messages will be
printed to the console.  It's possible that this message has a level
higher than 0, in which case you could set the level to something a
bit less draconian.  You can look at the kernel source, or just
experiment and find out.  Oh, and the "-2" part just says that when
klogd attempts to decipher kernel addresses, it should also log the
original, untranslated kernel address, since it is almost always using
the wrong System.map and therefore is translating the kernel addresses
incorrectly.

For anyone interested in a higher level view, here's how kernel
messages get printed to the console:

During bootup:

First, no messages are output until the console device has been
initialized.  Until then, the messages are saved in a buffer (named
"log_buf" last I checked) and when the console device (the video card
or the serial port usually) is initialized, all the messages saved in
the buffer are printed out.  Usually this happens fairly early in the
boot, so it just looks like the kernel has been printing out messages
all this time.  You can figure out when the console is initialized by
putting delays into init/main.c.  If the screen remains black during
your delay, then it is before the console is initialized, but if you
get some messages and then a pause, it's after the console is
initialized.

Once init scripts are run:

The "syslog" initialization script (found in /etc/rc.d/init.d/syslog)
runs the userlevel programs klogd and syslogd.  First, klogd grabs all
the kernel messages that have already been output and sends them to
syslogd, which logs them in /var/log/messages.  Then klogd continues
to run, filtering the kernel messages and letting some them go to the
console, and sending all of them to syslogd, which continues to log
them.

Note: The kernel message buffer is finite and will be overwritten if
you have a lot of messages during bootup.  So it's possible
/var/log/messages won't contain -all- your bootup messages, just the
most recent 16KB or so that were in the buffer when syslogd started.

More fun: Run "strace dmesg" to find the userlevel interface to the
kernel message buffer.  I thought my system would use something in
/proc, but I was wrong...

Whew.  That was long.

-VAL