4.1 System Logging


4.1 System Logging

Most system programs write their diagnostic output to the syslog service. The syslogd daemon waits for messages, and depending on the type of message received, funnels the output to a file, the screen, users, some combination of these, or just ignores it. The system logger is one of the most important parts of the system. When something goes wrong and you don't know where to start, you should check the system log files first. Here is a sample log file message:

 Aug 19 17:59:48 duplex sshd[484]: Server listening on 0.0.0.0 port 22. 

Most Linux distributions use the /var/log directory to store log files, but you can find out for sure by looking at syslog.conf , the syslogd configuration file. It contains lines like this:

 kern.*                      /dev/console *.info;authpriv.none        /var/log/messages authpriv.*                  /var/log/secure,root mail.*                      /var/log/maillog cron.*                      /var/log/cron *.emerg                     * local7.*                    /var/log/boot.log 

The type of information to be logged is on the left, and the place where it is logged to is on the right. Most of the log targets in this example are normal files, but there are some exceptions: /dev/console is a special device for the system console, root means to send a message to the superuser if that user is logged in, and * means to send a message to all users currently on the system. You can also send messages to another host with @ host .

Log messages carry a facility and a priority . The facility is a general category of message (Check the syslog.conf(5) manual page for a current list of all facilities). Most are fairly obvious from their name ( mail , for example). The preceding syslog.conf sample catches messages carrying the authpriv , mail , cron , and local7 facilities. In line 6, * is a wildcard that catches output related to all facilities.

In the syslog.conf file, the priority follows the dot (.) after the facility. The priority may be one of debug , info , notice , warning , err , crit , alert , or emerg . This is also the order of the priorities, with emerg being the highest.

Note  

You can exclude log messages from a facility in syslog.conf by specifying a priority of none , as shown on line 2 of the preceding example.

It is important to understand that when you put a specific priority in a syslog.conf line, syslogd sends messages with that priority and all higher priorities to the destination on that line. Therefore, in the preceding example file, the *.info actually catches most syslog messages and puts them into /var/log/messages because info is a relatively low priority. You can catch all priorities by using * as a wildcard.

An extra daemon called klogd traps kernel messages and (usually) sends them to syslogd . You may wish to direct kernel messages into a separate file with a line like this in your syslog.conf :

 kern.*                   /var/log/kern.log 

If you want to send a log message to the syslog service manually (for example, when writing a script), use the logger command, as in this example:

 logger -p daemon.info something bad just happened 

Very little can go wrong with syslogd . The most common problem is where syslog.conf doesn't catch a certain facility or priority. Another problem is that log files have a tendency to fill their disk partitions after some time. However, most distributions automatically trim the files in /var/log with automatic invocations of logrotate or some other utility.

The Linux syslogd has a few more features than its counterparts in other Unix variants. The discussion here only covers the basics that apply to most Unix systems. If you're really interested in it, or if there's some character in your configuration file that you can't figure out, take a look at the syslog.conf(5) manual page.




How Linux Works
How Linux Works: What Every Superuser Should Know
ISBN: 1593270356
EAN: 2147483647
Year: 2004
Pages: 189
Authors: Brian Ward

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net