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.