On RedHat 7, system logging is provided by systemd. The daemon is called journald (actually, systemd-journald) and it is accessed using journalctl.

All system messages start in journald. Some of the log messages (arguably the more interesting ones) are tagged and passed on to the standard legacy (though not deprecated) system log facility rsyslog. We will describe both journald and rsyslog in this section. The rsyslog facility in RH7 is pretty much unchanged from RH6, and the types of messages passed on to it (now by journald) are similar. Kernel logging, however, is only available from journald via its user interface, journalctl.

User processes also generate logging information and contact the 'system logger' via a library interface. journald evidently intercepts those logs as well, although they have been preformatted for rsyslog by the user processes. This is evident since these messages appear in both journald's logs and in rsyslog's files.

It is unknown at this time what the future of the legacy rsyslog will be. Currently, it serves the vital purpose of dividing log messages functionally, and making them persistent (by saving them on disk). Unless reconfigured, journald logs are kept only in memory. Except for those messages passed on to rsyslog, all log messages disappear at boot. It appears possible to filter journald messages by function and seems fairly simple to separate these out and save them in files, but, for the present, rsyslog is used for this. This may simply be to avoid disturbing the status-quo too much. The behemoth systemd is already raising eyebrows due to its takeover of so many functions.

Justification for rsyslog

Many system processes need to output status and informative messages periodically due to system events. Examples of these might be 

• a service is started 
• a user logs on or off, attempts to log on unsuccessfully, or changes user id using su
• a user executes a command using sudo either successfully or unsuccessfully

The rsyslog subsystem provides a simple common interface for logging system events such as these, providing configurable redirection and/or duplication of these various types of messages in different files and/or to other systems. It also provides a consistent format for the messages.

Suppose an unsuccessful attempt is made to log in at the GUI console as alex. Rather than having to decide what to do with this information, whatever program is handling the login (sshd, login, or, in this case, gdm) simply assembles a message specifying

• the type of message (called the facility). Here the facility would be authpriv, which indicates a secure authentication message
• the importance of the message (called the priority). In this case the priority is probably info or notice.
• the message itself. This contains a tag (usually the originator), and the message data. In this case, the tag would indicate the low-level authentication package that attempted the login (pam_unix) prehaps as well as the user program that initiated it (gdm - the gnome display manager)

Then the syslog function in the C library (syslog(3)) is invoked. This writes to the Unix domain socket (usually /dev/log), which rsyslogd (or now, probably, journald, which passes it on to rsyslogd) listens to. When rsyslogd gets the information, it logs it in the log file specified by /etc/rsyslog.conf, which determines where messages are logged based on their priority and facility, adding the date and the hostname.

In the example of an unsuccessful attempt to login at the GUI conosole as the existing user gboyd, my current system is configured to place the following message in /var/log/secure:

May  4 15:12:30 localhost pam: gdm-password[19885]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=:1 ruser= rhost=  user=gboyd

In this message you can see several parts: the timestamp, the host, the service (pam) and the module (pam_unix) and the message.

rsyslogd's configuration file /etc/rsyslog.conf details how rsyslogd is configured and where messages are logged. We will discuss that next.

Note: The rsyslog package, including rsyslogd(8) is referred to as rsyslogd, or rsyslog Its configuration file is rsyslog.conf and the subsystem is rsyslog. 

Next we will discuss journald. Then we will return to rsyslog and examine its configuration file.