Linux system logger “syslogd”-part 1 December 6, 2010Posted by Tournas Dimitrios in Linux.
syslog (system logging ) is a utility for tracking and logging all manner of system messages the levels are between informational to the extremely critical. Each system message sent to the syslog server has two descriptive labels associated with it that makes the message easier to handle.
- The first label describes the function (facility) of the application that generated it. For example, applications such as mail and cron generate messages with easily identifiable facilities named mail and cron.
- The second label describes the priority ( degree of severity ) of the message. There are eight levels of priority .
The tables below list some available facilities and priorities.
Syslog’s priorities :
|1||alerts||Immediate action required|
|5||notifications||Normal but significant conditions|
Syslog’s facilities :
|authpriv||authorization and security which may contain sensitive information.|
|cron||Clock related services (such as the crond and atd daemons).|
|daemon||System daemons without a separate facility|
|ftp||The ftpd daemon|
|kern||Kernel related messages (discussed in more detail below)|
|local0 through local7||These eight facilities can be used to define local policy. For example, Red Hat Enterprise Linux service scripts log to the local7 facility.|
|lpr||Print system related messages|
|Mail related messages|
|syslog||Messages related to syslogd|
|user||The default facility|
Once the message has been tagged with the appropriate facility and priority, it is passed to the syslogd daemon. What this daemon does with the received messages depends on its configuration file ” /etc/syslog.conf ” , this file defines what should be done with the various messages received by the syslogd daemon . Sample lines from the file might look like the following command :
[root@server ~]# less /etc/syslog.conf |grep message | grep -Ev “^#”
The second line specifies that all messages with a priority of informational or above which are not from the mail, news , authpriv, or cron facilities should be written to the regular file /var/log/messages. Each relevant line of the /etc/syslog.conf configuration consists of two whitespace separated tokens. The first token specifies which messages are relevant, and the second token specifies what to do with the message. The first token should consist of facility.priority pairs, where all messages from the specified facility equal to or higher than the specified priority are considered relevant. Multiple facility.priority pairs can be specified, separated by a semicolon. The wildcard character * can be used as expected to match all facilities or priorities. Note that later specifications on a single line have the potential to override the behavior of previous specifications on that same line . What to do with a message which matches a specification is called an action. The possible actions and their associated syntax are tabled below.
|/path/to/filename||The message should be appended to the specified file. Note that the file must be specified as an absolute reference.|
|username||The message should be written on the specified user’s console. If the user is not currently logged in, the message is lost.|
|@hostname||Forward the message to the specified hostname. Remote logging will be discussed in more detail below.|
|*||The special character * broadcasts the message to everyone currently logged in, similar to the wall command. Useful for very important messages.|
As always , when editing configuration files on Linux , ther related deamon must be restarted . After editing /etc/syslog.conf configuration file, the syslogd daemon should be restarted , with the following command , service syslog restart. When the syslogd daemon writes a message to a destination, it decorates the message with some additional information, as seen in the following /var/log/messages file.
Extracting a single message for closer study, we find that a syslog messages consist of the following components.
- The name of the application or facility which generated the message.
- All syslog messages are timestamped with the time the message was received.
- The hostname of the originating machine. This is most useful in the context of remote logging
- Sometimes, applications include their process ID in the log message as well.
- Finally, the message itself. There is no convention for what a message should contain.It depends what text – string has been registered to a specific error during the programming cycle
Not all applications use the syslog service. Many more sophisticated applications implement their own log file or files. The filename and message format of the application specific log files are completely dependent on the application. By convention, however, all applications which log (including the syslog service) should store their log files within the /var/log directory.
The following table list some commonly used log files, and their customary purpose.
|/var/log/messages||The default system logfile|
|/var/log/secure||The system logfile for possibly sensitive information|
|/var/log/up2date||The log file for up2date (which coordinates with Red Hat Network)|
|/var/log/httpd/access_log||The Web Server’s transaction log|
|/var/log/cups/access_log||The CUPS print service transaction log|
|/var/log/cups/error_log||The CUPS print services error log|
|/var/log/samba/||Various log files for the Samba SMB fileserver|
Generating custom Log messages :
The logger command allows administrators to easily generate log messages. The tool is used for both debugging the syslog service, and for reporting conditions from within shell scripts. The logger command uses the following syntax.
logger [-is] [-p pri] [-t tag] message ...
|-i||Include the Process ID with the message|
|-s||Duplicate the log message on standard error.|
|-p pri||The priority as a facility.level pair. Defaults to user.notice.|
|-t tag||Tag to include with the message. Often the application name.|
Kernel Logging :
Like user and system applications, the kernel itself occasionally creates log messages. Unlike applications, the kernel has no access to either the filesystem or the syslogd daemon. Instead, kernel log messages are stored in an internal fixed length buffer referred to as the dmesg buffer.
Kernel messages can be examined by user applications two different ways. First, a user can run the dmesg command, and the contents of the dmesg buffer will be dumped to standard out. Secondly, kernel messages can be read by any process reading from the special file /proc/kmsg. The klogd daemon does just this.
The klogd daemon servers as a kernel message to syslog message proxy. It spends its life reading the file /proc/kmesg, and whenever the kernel emits a message, it “rewraps” the message, forwarding it to the syslogd daemon using the kern facility. Therefore, kernel messages are also logged in the file /var/log/messages, just like application messages.