Bruce Dubbs wrote: > Bryan Kadzban wrote: >> David Jensen wrote: >>> from slackware rc.syslog >>> # '-c 3' = display level 'error' or higher messages on console >> Starting to get off topic now, but after reading the klogd manpage, this >> is exactly what the current LFS bootscripts do when you set LOGLEVEL in >> /etc/sysconfig/console, and the /etc/rc.d/init.d/consolelog script runs: >> >> dmesg -n $LOGLEVEL >> >> So you could accomplish exactly this with the stock bootscripts, just by >> setting LOGLEVEL=3 there; no change required to the klogd script. >> >> (Well, almost "exactly this". Setting the value to 3 doesn't display >> "level 'error' or higher" on the console. 3 is KERN_ERR, but the kernel >> displays only messages *worse* than the level you set. So you get >> "levels higher than 'error'" on the console: KERN_CRIT, KERN_ALERT, and >> KERN_EMERG. But that's the case with klogd as well; your comment >> doesn't match the arguments given. :-) ) > > Its a learning situation for most of us. > > The section of the code in question uses LOG_ERR, LOG_WARNING, and LOG_INFO.
Yeah, those are the constants used for syslog(3) calls (sending the
messages over the /dev/log socket to syslogd). But the kernel defines
are KERN_{ERR,CRIT,ALERT,EMERG,...} (including a bunch of other levels
less severe than ERR); these get turned into the <X> three-character
prefix on the kernel messages. (The value of X is the value of the
define, so it's 0 for KERN_EMERG, 1 for KERN_ALERT, etc.)
klogd then strips the <X> prefix, and turns these messages into syslog()
calls (...I think anyway) with the appropriate LOG_* constant based on
the prefix it saw.
But totally separate from that process, the kernel also decides whether
to write the message to the current console, based on the kernel.printk
sysctl. (Which "dmesg -n" and "klogd -c" both manipulate.)
> For LFS, I don't think any kernel messages should be thrown out except
> maybe DEBUG when not trying to actively solve a problem.
Yeah, but we leave it up to the user at least, and the method for
changing the proper sysctl is already in the bootscripts. No need to
add any -c support to the sysklogd script.
> dmesg -n $LOGLEVEL only prevents logging to the console.
Yep, and only by the kernel. According to the klogd manpage, this is
exactly what "klogd -c" does, as well. :-)
Running klogd with other options keeps it running in the background, and
it keeps reading /proc/kmsg and sending the messages to syslogd.
(Although running it with just -c might also leave it running in the
background as well, I've never tried that.)
> "all levels of messages are still written to /proc/kmsg, so
> syslogd(8) can still be used to control exactly where kernel messages
> appear."
Indeed. You can even configure syslogd to write them to /dev/console if
you really want to (I think). But then you don't see the messages
unless the kernel, klogd, and syslogd are all working; if you have the
kernel do it then there's only one point that might fail.
> I guess my point is not so much that I want to suppress the error
> message, but I want to control when the System.map is read which avoids
> the error (and the message).
Yeah, that's why this was starting to get off topic. :-)
> The easiest way to do that is to pass -x unconditionally.
Indeed. Given the pointlessness of having System.map around, I'd do
exactly that (I see no downside, since I don't know of any reason to use
System.map at all) -- but I'll leave it up to you.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
