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
The "debug" is the lowest level. Everything above the level you specify goes to wherever you say; "*" is all of them and the tag "none" is none of them. See "man syslog.conf" for examples.
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) - and ssh is hardly the only program that logged things in unexpected ways.
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:
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
logger -t $i -p local6.$i $i
You could also do:
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:
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-
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).
this is for kernel logging, not application logging.