Understanding rsyslog

The old syslog logging system was created back in the 1980s for use on Unix and other Unix-like systems. It finally saw its last days in the Linux world only a few years ago. Nowadays, we use rsyslog, which is a bit more robust and has a few more features. It works mainly the same on both Debian-based and Red Hat-based distros, with only some differences in how the configuration files are set up. But, before we look at the differences, let’s look at what’s the same.

Understanding rsyslog logging rules

Logging rules define where to record messages for each particular system service:

  • On Red Hat/CentOS systems, the rules are stored in the /etc/rsyslog.conf file. Just scroll down until you see the #### RULES #### section.
  • On Debian/Ubuntu systems, the rules are in separate files in the /etc/rsyslog.d/ directory. The main file that we care about for now is the 50-default.conf file, which contains the main logging rules.

To explain the structure of an rsyslog rule, let’s look at this example from a CentOS 8 machine:

authpriv.*           /var/log/secure

Here’s the breakdown:

  • authpriv: This is the facility, which defines the type of message.
  • .: The dot separates the facility from the level, which is the next field.
  • *: This is the level, which indicates the importance of the message. In this case, we just have a wildcard, which means that all levels of the authpriv facility get logged.
  • /var/log/secure: This is the action, which is really the destination of this message. (I have no idea why someone decided to call this an action.)
  • When we put this all together, we see that authpriv messages of all levels will get sent to the /var/log/secure file.

Here’s a handy list of the predefined rsyslog facilities:

  • auth: Messages generated by the authorization system (login, su, sudo, and so forth)
  • authpriv: Messages generated by the authorization system but which are only readable by selected users
  • cron: Messages generated by the cron daemon
  • daemon: Messages generated by all system daemons (for example, sshd, ftpd, and so forth)
  • ftp: Messages for ftp
  • kern: Messages generated by the Linux kernel
  • lpr: Messages generated by the line printer spooling
  • mail: Messages generated by the mail system
  • mark: Periodic timestamp message in the system log
  • news: Messages generated by network news system
  • rsyslog: Messages generated internally by rsyslog
  • user: Messages generated by users
  • local0-7: Custom messages for writing your own scripts

Here’s a list of the different levels:

  • none: Disables logging for a facility
  • debug: Debug only
  • info: Information
  • notice: Issues to review
  • warning: Warning messages
  • err: Error conditions
  • crit: Critical condition
  • alert: Urgent messages
  • emerg: Emergency

Except for the debug level, whatever level you set for a facility will cause messages of that level up through emerg to get logged. For example, when you set the info level, all messages of the info levels through emerg get logged. With that in mind, let’s look at a more complex example of a logging rule, also from a CentOS 8 machine:

*.info;mail.none;authpriv.none;cron.none /var/log/messages

Here’s the breakdown:

  • *.info: This refers to messages from all facilities of the info level and higher.
  • ;: This is a compound rule. The semicolons separate the different components of this rule from each other.
  • mail.none;authpriv.none;cron.none: These are the three exceptions to this rule. Messages from the mail, authpriv, and cron facilities will not get sent to the /var/log/messages file. These three facilities have their own rules for their own log files. (The authpriv rule that we just looked at earlier is one of them.)

The rules on an Ubuntu machine aren’t exactly the same as the ones on a CentOS machine. But, if you understand these examples, you won’t have any trouble figuring out the Ubuntu rules.

If you ever make changes to the rsyslog.conf file or add any rules files to the /etc/rsyslog.d directory, you’ll need to restart the rsyslog daemon to read in the new configuration. Do that with this:

[donnie@localhost ~]$ sudo systemctl restart rsyslog
[sudo] password for donnie:
[donnie@localhost ~]$

Now that you have a basic understanding of rsyslog, let’s look at journald, which is the new kid in town.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur


Submit a Comment

Your email address will not be published. Required fields are marked *

one × five =