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.

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.

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.

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.

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.