log level (configuring syslog)

© April 2005 Tony Lawrence

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. 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:

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.

See also Logger

Accepting logging from other hosts

SCO 5.0.6 syslogd added a "-r" flag - without it, it will not accept logging from other hosts.

On Ubuntu Linux, I had to uncomment these lines in /etc/rsyslog.conf:

$ModLoad imudp
/etc/rsyslog.conf:$UDPServerRun 514
 

and restart the syslog server.

/etc/init.d/rsyslog restart
 

Even Windows can write to a syslog server ..

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us