sections in this module City College of San Francisco - CS260A
Unix/Linux System Administration

Module: rsyslog
module list

rsyslog.conf files

Note: rsyslog has changed significantly in the last few years, effectively introducing a programming-language interface into the configuration file and giving the administrator much finer control over log messages. We won't cover these features due to time and due to the pre-emption of logging responsibilities by systemd-journald.

As discussed in the Introduction, the rsyslog package provides a consistent framework for logging system messages. Messages are received by the rsyslog daemon, rsyslogd, through a local socket or through a network port, if the message was logged remotely. Once the message is received, rsyslogd must decide what to do with it. This is the traditional purpose of the configuration file /etc/syslog.conf and this section of the new file /etc/rsyslog.conf (called the rules section) has the same format and syntax as the traditional syslog.conf file. We will cover the rules section of rsyslog.conf later in this section.

The rsyslog.conf file has sections that were not in the traditional syslog.conf. These sections usually appear first in the file. We will cover only the global directives section, which is divided into two parts:

Unfortunately, this has become so complex with the recent release that a complete discussion is beyond our scope (and beyond mine at this writing.) We will, however, introduce the two directives sections so that we can use the most interesting rsyslogd feature, remote logging.

Although the directives to enable remote logging are covered here, remote logging will be covered more completely in a later section in this module.

Important Notes:

Module directives

To enable a module, use the directive


where modname is one of the module names listed below. There are several modules that should always be loaded, and a few that are of interest in our brief look at rsyslogd. Modules are classified as input, output, or library. We will only cover a few modules, and they are all input modules:

module name
capability enabled
enable kernel logging. (This should be loaded)
enable reading log messages from local Unix domain sockets. From the documentation: "you need to have this module loaded to read the system log socket and be able to process log messages from applications running on the local system". So this better be loaded too.
enable reading remote log messages via UDP. Should be accompanied by the directive
$UDPServerRun 514
which says to start a UDP server listening on port 514 (the standard rsyslog port)
similar to imudp, but uses TCP protocol for logging. Similarly there is a $TCPServerRun directive to accompany it.

There are many more modules. The interested reader is referred to the documentation in /usr/share/doc. As indicated, you should definitely have the first two modules loaded, as well as either of the other two, if you want to allow rsyslogd to log remote messages. (Note: this means rsyslogd will log the message on the local machine. The event occurred on a remote machine.) Again, although the directives to enable remote logging are covered here, remote logging will be covered more completely in a later section.

Other directives

The only other directives we will cover are those that specify the output of log messages. Traditional syslog had a standard format for logging messages - rsyslog provides for the specification of message templates so that the administrator can log messages as she prefers. The two directives we will cover set rsyslogd's format for logging local and remote messages.

Most templates are user-defined. However, if the template name starts with RSYSLOG_, the template name is reserved for an internal rsyslog template. The two that we are interested in are

RSYSLOG_TraditionalFileFormat  - the traditional format for local messages

RSYSLOG_TraditionalForwardFormat - the traditional format for messages forwarded to a remote machine. (Note: using this strangely duplicates the hostname when forwarding to a machine running sysklogd.)

Here are the two directives of interest:
$ActionFileDefaultTemplate (followed by the template name) sets a new default template for outputting messages to log files
$ActionForwardDefaultTemplate (followed by the template name) sets a new default template for UDP and plain TCP forwarded messages
$ActionFileEnableSync (followed by on or off) allows sync-ing of log files after each write. syslog used to always sync the log files after writes. rsyslogd does not, so this directive is off by default.

Here are the current default directives in rsyslog.conf:

#### MODULES ####



# Provides UDP syslog reception
#$UDPServerRun 514

# Provides TCP syslog reception
#$InputTCPServerRun 514


# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#$ActionFileEnableSync on

As you can see, many of them are commented out. Since this version of rsyslog does not accept log messages from another machine (remote logging), no servers are started on either a UDP or TCP port. In addition, there is no $ActionForwardDefaultTemplate, so it will use the new rsyslog message format when forwarding messages to a remote machine.

The rules section

This section configures which messages get logged where. To begin with, let's look at the format of an rsyslog message. Each message consists of the message text itself, a tag, and two values used to classify the message:

The /etc/syslog.conf file consists of multiple rules. Each rule is one or more lines. Rules that continue to a second or later line must have their newlines escaped. The format is simply two fields separated by whitespace:

selector         action

Where selector is a list of facility priority specifiers in the format facility.priority, and action is the destination for the log message. Each message whose facility matches that of the selector and whose priority is at least as high as the priority in the selector, is logged to the destination. For example, the rule below    /var/log/secure

logs all messages with the facility authpriv and the priority info or higher in the log file /var/log/secure.

Lines starting with # and empty lines are ignored.

More complex selectors

Complete control over which facility.priority combinations result in an action is provided by additional syntax:


Suppose you want two logs of mail messages. You want info messages to go to /var/log/ and all other mail messages to go to /var/log/mail. This could be accomplished by the two rsyslog.conf lines below:

mail.*;mail.!=info    /var/log/mail

mail.=info    /var/log/

We want to log all messages of info level or higher in /var/log/messages, except kern messages:

*.info;kern.none    /var/log/messages

As discussed previously, these configuration changes should be placed in a new file in /etc/rsyslog.d, and rsyslog restarted.

action syntax

The action is normally a file, in which case it must have an absolute path. The file is normally synced (flushed) after the message has been written. (Note: this was the default behavior with sysklogd. rsyslogd evidently has turned off this behavior, but put it under control of the $ActionFileEnableSync directive.)

Other syntax includes

More examples

The rsyslog.conf(5) man page on linux has many additional examples. Check it out.

Preview question: Re-examine /etc/rsyslog.conf and /etc/rsyslog.d/* and note what types of log messages are logged to the different log files. Then list the master log directory on linux and note the different log files and their extensions. Can you surmise why there are several versions of the messages file?

Prev This page was made entirely with free software on linux:  
the Mozilla Project, Kompozer,

Copyright 2015 Greg Boyd - All Rights Reserved.
                    made with Kompozer