Understand rsyslog configuration file order

Rsyslog processes included configuration at the point where the include appears. For a wildcard include such as /etc/rsyslog.d/*.conf, matching files are read in filename sort order. Rules in that resulting configuration execute sequentially within their ruleset.

Locate the include first

A traditional main configuration may contain:

$IncludeConfig /etc/rsyslog.d/*.conf

Newer configurations can use:

include(file="/etc/rsyslog.d/*.conf" mode="optional")

These are alternatives; do not add both for the same files. The modern include() object is available from rsyslog 8.33.0. An include need not be at the end of the main file: rules before and after it retain their positions.

Think of the snippets as inserted text, not independent files whose settings automatically override one another. The include reference describes this expansion.

Order specific rules before general ones

A file named 10-myapp.conf can route one application:

if ($programname == "myapp") then {
    action(type="omfile" file="/var/log/myapp.log")
    stop
}

A later file, such as 50-default.conf, can contain the general file actions. Messages handled by the earlier stop will not continue to those later rules in the same processing path.

Without stop, writing to one file does not consume a message. Additional matching actions may also run. That is useful for intentional fan-out, but two overlapping actions targeting the same file can write duplicates.

Keep filenames and scope predictable

Use consistent, zero-padded numeric prefixes: 10-base.conf, 20-application.conf, and 50-default.conf. This is filename ordering, not numeric parsing; 100-extra.conf can sort before 20-application.conf. An unprefixed app.conf follows the same filename-sort rules.

Named rulesets change the processing path: an input bound to a ruleset does not automatically run every rule in the default one. Review the ruleset as well as the filename when a message appears to skip a configuration fragment.

Do not rely on a blanket “last value wins” rule for duplicate global parameters, modules, or named templates. Some declarations are invalid when repeated, and different legacy directives have different scope. Configure each deliberately and remove accidental duplicates.

Validate the change

sudo rsyslogd -N1
sudo systemctl restart rsyslog.service
logger -t myapp 'Configuration order test'

Check both the dedicated file and the general destination. Syntax validation catches parsing problems; only a routing test confirms whether a message reaches exactly the destinations you intended. The ordering tutorial gives another example of how an early stop changes later actions.