Loglevel
Syslog is a wonderful thing. In theory, it lets an administrator fully control where and how messages get logged. Of course, the first requirement is that the program you wish to control uses syslog for logging, but even assuming that it does, it can still be difficult to get what you want.
Part of the problem is that many programs that do in fact use syslog don’t bother to document exactly how they do so. Any program that wants to have syslog handle its logging simply has to call syslog (man 3 syslog) specifying a facility (one of auth,authpriv,cron,daemon,ftp,kern,lpr,mail,news,user or local0 through local7), and a priority (one of emerg, alert, crit err,warning,notice,info or debug). The default /etc/syslog.conf file can be edited to send any combination of of these to different places. But for you to control that, or even know where the logging will go, you’d have to know what facility the programmer chose. If you have source, of course that’s easy enough. Without source, you have to rely on documentation or experimentation. But even if you have documentation, it may be confusing or misleading; see, for example, Sshd non-intuitive logging setting. (priority names)
OK. You’ve read the man page for syslogd and syslogd.conf and you’d determined that your program uses the local6 facility and you want to send all of its logging to the screen. What could be more simple? Add this to /etc/syslog.conf:
local6.* *
Restart syslog (kill -1 `cat /var/run/syslogd.pid`) and you are done. You can test this with the “logger” program:
for i in debug info notice warn err crit alert emerg
do
logger -t $i -p local6.$i $i
done
You could also do:
local6.* /dev/console
which behaves slightly differently. Esxperiment with the “logger” program to see what the differences are. The * logs each message separately and notifies all logged in users; /dev/console will group messages and only prints to console users.
If instead you do:
local6.crit *
Then only messages tagged crit,alert, and emerg will appear on the screen. See “man 8 syslogd” for more control options.
If you don’t have documentation, you have to experiment with different syslog.conf configurations until you figure out just what the program really is using. This can be annoying and time consuming.
Things are a bit different if the program is a driver using kernel logging. In that situation, you also have to understand how the kernel interprets /proc/sys/kernel/printk if you wanted it print (or not print) to the system console. Here’s the section of the proc man page that pretends to explain it:
The four values in the file printk are console_loglevel,
default_message_loglevel, minimum_console_level and default_con-
sole_loglevel. These values influence printk() behavior when
printing or logging error messages. See syslog(2) for more info
on the different loglevels. Messages with a higher priority
than console_loglevel will be printed to the console. Messages
without an explicit priority will be printed with priority
default_message_level. minimum_console_loglevel is the minimum
(highest) value to which console_loglevel can be set.
default_console_loglevel is the default value for con-
sole_loglevel.
That’s pretty awful, I think. For one thing, it refers to “minimum_console_level” in the first sentence and “minimum_console_loglevel” later. It does the same renaming of “default_message_loglevel”. Well, you can probably get by that. But from that paragraph, what do you suppose the difference is between console_loglevel and default_console_loglevel? A /proc/sys/kernel/printk might contain:
6 4 1 7
Did that help your understanding? Probably not. And what is the point of minimum_console_loglevel? Well, one thing to be aware of is that the syslog call can change the default log level, and can reset it to the default as read from this file. But it can’t set it lower that minimum_console_loglevel.
So what does that “6 4 1 7″ actually mean? Well, with that setting, kernel printk messages with a priority above debug would appear on the console. If you look at sylog(2) as you are advised, you’ll find the levels defined as :
#define KERN_EMERG "<0>" /* system is unusable */
#define KERN_ALERT "<1>" /* action must be taken immediately */
#define KERN_CRIT "<2>" /* critical conditions */
#define KERN_ERR "<3>" /* error conditions */
#define KERN_WARNING "<4>" /* warning conditions */
#define KERN_NOTICE "<5>" /* normal but significant condition */
#define KERN_INFO "<6>" /* informational */
#define KERN_DEBUG "<7>" /* debug-level messages */
To get less, set the console_loglevel lower, for more set it higher (though anything above 8 is pointless). Remember: this is for kernel logging, not application logging.
If you found this post useful you may also want to check these out:
