The /dev/log socket is created by the system logger (which we have very briefly discussed previously) and is made writeable for everyone. That is to be expected, as there are many tools that will log through this socket. Every tool that wants to log through the system logger logs a single line at a time inside this socket. The system logger is listening "on the other side" of the socket and will process these log events.

You will most likely never need to write your own tool that logs through the system logger, yet understanding how a log event is sent is vital if you want to manage your log files properly. The reason for this is because you will want to filter based on criticality and origin of the events, and these are passed on as part of the log event itself.

When a tool wants to log an event, he needs to provide two additional fields:

The facility defines the type of the program that is sending out the event. This allows the system logger to properly filter messages, possibly sending them into different log files. Example facilities are authpriv (security/authorization messages), cron (scheduling messages) and kern (kernel messages). A full list of facilities can be obtained through the syslog man page

~$ man 3 syslog

The importance level defines the criticality of the event. The set of supported importance levels is:

Based on these two fields, log messages are then filtered by the system logger into one or more log files.

How a system logger is configured depends on the system logger you use. In this book, I'll focus on the syslog-ng logger.

The configuration file for syslog-ng is /etc/syslog-ng/syslog-ng.conf. An example configuration is displayed below.

@version: 3.0
options {
  stats_freq(43200);
};

source src {
  unix-stream("/dev/log" max-connections(256));
  internal();
  file("/proc/kmsg");
};

destination messages { file("/var/log/messages"); };
destination cron { file("/var/log/cron.log"); };
destination auth { file("/var/log/auth.log"); };

filter f_messages { not facility(cron, auth, authpriv); };
filter f_cron { facility(cron); };
filter f_auth { facility(auth, authpriv); };

filter f_warnplus { level(warn, err, crit, emerg); };

log { source(src); filter(f_cron); filter(f_warnplus); destination(cron); };
log { source(src); filter(f_auth); destination(auth); };
log { source(src); filter(f_messages); destination(messages); };

It might be easy to read the configuration file from the bottom up.

This fairly simple example immediately shows how flexible the logs can work. There are many more interesting filters you can apply, such as match() to match regular expressions within the logged event and program() to match log events of a particular tool.

The Xorg server stores it log file at /var/log/Xorg.0.log. The trailing 0 denotes that this is of the current/last start. The log file of the start before that is called Xorg.1.log, and so on.

Xorg uses the following notations to identify the various criticality levels:

Markers: (--) probed, (**) from config file, (==) default setting,
   (++) from command line, (!!) notice, (II) informational,
   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.

The Xorg server will automatically rotate the log files, by default 3 times, after which it will erase the oldest log file.

First, install logrotate:

~# emerge logrotate

Next, make sure that it is scheduled to be ran every day. For instance, you can have a script called logrotate.cron inside /etc/cron.daily with the following content (Gentoo users will have this as part of the installation):

#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf

To configure logrotate, create configuration files inside /etc/logrotate.d. For instance, the following /etc/logrotate.d/syslog-ng helps us rotate the log files that we identified as part of the system logger configuration:

/var/log/messages /var/log/cron.log /var/log/auth.log {
  rotate 6
  monthly
  # It is ok if a log file is missing
  missingok
  # Only execute postrotate after all 3 log files are rotated
  # instead of after each log file
  sharedscripts
  # Commands to run after the rotation has occurred
  # This will instruct syslog-ng to reload its configuration
  # and log files
  postrotate 
    /etc/init.d/syslog-ng reload > /dev/null 2>&1 || true
  endscript
}

The file informs logrotate that the mentioned log files are rotated 6 times on a monthly basis (so you keep 7 months of history). The tool will automatically rename the "old" log files by adding a date stamp to the filename. You can also instruct logrotate to compress the rotated log files or even move them to a different location.