syslog

Syslog defines a message model and transport conventions used by many Unix-like systems. Rsyslog is one implementation that can receive, filter, transform, store, and forward messages. It may coexist with systemd-journald; neither name means that every application uses that path.

Facilities and Severities

A syslog message carries a facility describing its broad source category and a severity from emergency through debug. Common facilities include auth, cron, daemon, kern, mail, user, and local0 through local7.

Severities are ordered. In classic selector syntax, daemon.warning normally matches daemon messages at warning and all more severe levels, not warning alone. Exact matching uses an equals modifier in implementations that support the classic syntax, such as daemon.=warning.

CheckWhat does a classic selector such as daemon.warning normally match?

Only messages whose text contains the word daemon. Every debug message from every facility. Warning messages and more severe daemon messages.

Reading rsyslog Rules

Rsyslog commonly loads a main file and snippets under /etc/rsyslog.d/. A traditional rule has a selector followed by an action:

auth,authpriv.*          /var/log/auth.log
*.*;auth,authpriv.none  -/var/log/syslog
kern.*                  /var/log/kern.log

The first line routes all priorities from two authentication facilities. The second broadly selects messages and excludes those facilities. The third routes kernel-facility messages. A leading - on a file action commonly requests asynchronous writes; it does not mean exclusion.

Inspect all included files and validate the exact syntax used by the installed version before changing production routing.

CheckIn a traditional rsyslog rule, what is the action?

The facility and severity expression on the left. The destination or operation on the right. The comment describing the package version.

Sending a Test Message

Use logger to submit a controlled test with an identifiable tag and priority:

$ logger -p user.notice -t lesson-test 'routing check 2026-08-31T10:00'

Then query the expected destination, for example:

$ journalctl -t lesson-test --since '5 minutes ago'

The same event can appear in the journal and a text file, depending on forwarding and routing. logger -s also copies the message to standard error; it does not prove durable storage.

CheckWhat does logger -t lesson-test add to the submitted message?

A request to erase older test records. The identifier lesson-test as the message tag. A five-minute delivery delay.

Changing and Verifying Routing

Before a change, save the current configuration and identify downstream consumers. Validate syntax with the implementation's configuration-check mode, commonly:

$ sudo rsyslogd -N1

Only after validation should you reload the service through its manager. Send a new tagged message, verify every required destination, and check service status and internal error logs. A syntactically valid rule can still route too broadly, duplicate records, or expose sensitive data.

Remote forwarding should use authenticated, encrypted transport when logs cross untrusted networks. UDP delivery has no end-to-end acknowledgement; critical audit requirements need a design that accounts for queues, loss, integrity, access control, and receiver outages.

CheckWhat is sufficient evidence that a new routing rule works?

The configuration file has a recent modification time. The sender can reach the receiver with a ping. Validation passes and a tagged test reaches every intended destination.

Summary

You can now test syslog routing from message metadata to its configured destination.

1. Distinguish facilities from ordered severity levels.
2. Read selectors separately from their actions.
3. Send a tagged, prioritized event with logger.
4. Validate configuration and verify delivery end to end.