|sections in this module||City
College of San Francisco - CS260A
Unix/Linux System Administration
discussed in the Introduction, the rsyslog package provides a consistent
for logging system messages. Messages are received by the rsyslog
through a local socket or through a network port, if the message
was logged remotely. Once the message is
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 documentation section.
file has sections that were not in the traditional syslog.conf.
These sections usually appear first in the file. We will cover
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
writing.) We will, however, introduce the two directives sections
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 Note: The
mechanism for getting a daemon to reread its configuration file is
send the daemon a HUP signal. A HUP signal will only cause rsyslogd to close and
reopen its log files. If you modify its configuration file you
should restart the
daemon using service.
To enable a module, use the directive
is one of the module names listed below. There are several modules
should always be loaded, and a few that are of interest in our
look at rsyslogd.
Modules are classified as input, output, or library. We will only
cover a few modules, and they are all input modules:
||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
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
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
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
are covered here, remote logging will be covered more completely
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
- the traditional format for messages forwarded to a remote
(Note: using this strangely duplicates the hostname when
a machine running sysklogd.)
|$ActionFileDefaultTemplate||(followed by the template
name) sets a new default template for outputting messages to
|$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
sync the log files after writes. rsyslogd does not, so this
is off by
# Provides UDP syslog reception
# Provides TCP syslog reception
#### GLOBAL DIRECTIVES ####
# Use default timestamp format
As you can see, many of them are commented out. Since this
version of rsyslog
does not accept log messages from another machine (remote
servers are started on either a UDP or TCP port. In addition,
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:
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
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:
facility1,facility2,facility3.priority indicates the same priority for each facility. The rule matches messages with any of the given facilities (and with priority at least as high) as that indicated.
* in either the facility or priority position matches all possible values. Thus, mail.* and mail.debug are the same.
none as a priority indicates no priorities match.
if the priority is prefixed by =, only that priority exactly matches. Thus mail.=err only matches mail messages with the priority err. Normally mail messages with priority err or higher would match.
if the priority is prefixed by !=, that priority only is excluded. If the priority is prefixed by !, that priority and all higher priorities are excluded.
facility1.priority1;facility2.priority2 The rule matches messages just like two separate rules with the same action. Here, the selectors may overlap, with later selectors modifying earlier ones. This allows the use of the *, =, or ! modifiers above to select exactly the facility.priority combinations you want.
Suppose you want two logs of mail messages. You want info messages to go to /var/log/mail.info and all other mail messages to go to /var/log/mail. This could be accomplished by the two syslog.conf lines below:
We want to log all messages of info level or higher in /var/log/messages, except kern messages:
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
if the path to the log file is prefixed with a
dash the logfile is not synced after each message. Note that this is the default with rsyslogd
anyway, and can be countered with the $ActionFileEnableSync
directive. If the default (not syncing) is left in place,
messages may be lost if there is a system crash, but read the
messages about $ActionFileEnableSync
on the Internet before you add it. It may be a serious
the action may be a tty device path, or /dev/console to write the logfile to a specified tty
the action may be a user name to write the message to the terminal of the specified user if they are logged in
if the action is *, the message is broadcast as a wall message.
the action may indicate a domain name or IP address of another machine, prefixed with @. This is a request for rsyslog to log the message remotely to that machine. Remote logging is discussed in the section on Security Issues.
The rsyslog.conf(5) man page on linux has many additional examples. Check it out.
|Preview question: Re-examine /etc/rsyslog.conf 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 and Openoffice.org