jump to navigation

Linux system logger “syslogd”-part 1 December 6, 2010

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

Severity Level Keyword Description
0 emergencies System unusable
1 alerts Immediate action required
2 critical Critical condition
3 errors Error conditions
4 warnings Warning conditions
5 notifications Normal but significant conditions
6 informational Informational messages
7 debugging Debugging messages

Syslog’s facilities :

Facility Keyword Role
auth user authorization
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 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 “^#”
*.info;mail.none;news.none;authpriv.none;cron.none   /var/log/messages

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.

Syntax Action
/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.

Filename 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 ... 
Switch Effect
-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.


1. Linux system logger “syslogd”-part 2 « Tournas Dimitrios - December 6, 2010

[…] The first part of this article made an introduction to Linux logging . This second part is optional , it is focused to users with administration needs . Lets recap the basic concepts  of the first part : […]

2. Pradeep - March 19, 2011

superb explanation for a beginner.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s