level (configuring syslog)

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.

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.