Add and Safely Test a Per-Program rsyslog Log

You will route messages tagged demo-app into /var/log/demo-app.log, validate the complete rsyslog configuration, send one test message, and remove the rule if it is not wanted. The commands match rsyslog 8.2312.0 from Ubuntu package 8.2312.0-3ubuntu9.4 installed on this machine. Allow about fifteen minutes, including a short service restart.

You need a shell, an account with sudo access, and a running rsyslog service. The example writes a new log file and restarts the logger, so use a maintenance window if losing a few seconds of local logging would matter.

1. Check the daemon and its configuration paths

Start with read-only checks. They confirm which binary is installed and show the main configuration file that it will read:

$ command -v rsyslogd
/usr/sbin/rsyslogd
$ rsyslogd -v
rsyslogd  8.2312.0 (aka 2023.12) compiled with:
...
        Config file:                         /etc/rsyslog.conf
        PID file:                            /run/rsyslogd.pid
$ systemctl is-active rsyslog
active

The exact feature list from -v is longer than the excerpt. The installed rsyslogd(8) manual describes /etc/rsyslog.conf as the default and this host's binary reports /run/rsyslogd.pid. The main file includes /etc/rsyslog.d/*.conf, so a numbered drop-in is the least intrusive place for this rule.

2. Create one numbered drop-in

Choose a name that sorts after the existing general rules only when you intend that ordering. Here, 30-demo-app.conf is early enough to route the message before later rules can process it. Open the file as root:

$ sudoedit /etc/rsyslog.d/30-demo-app.conf

Replace the file contents with this small RainerScript rule:

# Keep messages from the demo-app tag in their own file.
if $programname == 'demo-app' then {
    action(type="omfile" file="/var/log/demo-app.log")
    stop
}

The property comparison tests the program name extracted from the syslog tag. omfile appends to the named file, creating it if needed. The stop statement prevents this message from continuing through later rules in the configuration. It does not stop rsyslogd or affect messages from other programs.

Save the file and inspect it without changing it:

$ sudo sed -n '1,20p' /etc/rsyslog.d/30-demo-app.conf
# Keep messages from the demo-app tag in their own file.
if $programname == 'demo-app' then {
    action(type="omfile" file="/var/log/demo-app.log")
    stop
}

3. Validate the complete configuration

Validate the real main file, not only the new fragment. The include order, module loads and earlier rules are part of the configuration that will actually run:

$ sudo rsyslogd -N1 -f /etc/rsyslog.conf
rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

Exit status zero and the final End of config validation run line are the useful result. The -N option checks configuration and does not start the daemon in normal mode. Keep -f /etc/rsyslog.conf explicit when troubleshooting, because it makes the file under test obvious.

4. Apply the rule with a controlled restart

This Ubuntu unit reports that it cannot perform a live reload, so apply the validated change with a restart:

$ sudo systemctl restart rsyslog
$ systemctl is-active rsyslog
active

This is the first service-disrupting command in the guide. It can briefly interrupt local log collection. If the restart fails, do not keep sending test messages. Check the service result and recent journal output:

$ systemctl status --no-pager rsyslog
$ journalctl -u rsyslog -n 40 --no-pager

If the service does not return to active, remove or correct the drop-in, validate again, and restart only after validation succeeds.

5. Send one tagged test message

Use the installed logger(1) command to send a harmless, identifiable message through the local Unix logging socket:

$ logger --tag demo-app 'rsyslog routing test'
$ sudo tail -n 5 /var/log/demo-app.log
Sep 26 20:00:00 host demo-app[1234]: rsyslog routing test

The timestamp, host and process ID will differ. The important checks are that the file exists, the line contains demo-app, and the test text appears. If the file is absent, check the restart status and journal first. If it exists but has no new line, verify the exact tag with logger --tag demo-app, then inspect the rule spelling and ordering.

Messages without that tag should not be written by this rule. This does not prove that another existing rule will not also write them to a general log such as /var/log/syslog; it only proves the new action's routing behaviour.

6. Undo the example without losing the old logs

Removing the configuration stops future writes from this rule. It does not delete the log already created. That separation is useful when investigating a failed change:

$ sudo rm /etc/rsyslog.d/30-demo-app.conf
$ sudo rsyslogd -N1 -f /etc/rsyslog.conf
$ sudo systemctl restart rsyslog
$ systemctl is-active rsyslog
active

The rm command is deliberately limited to the exact drop-in. Do not use a wildcard in this recovery step. If you need the old test file for evidence, leave /var/log/demo-app.log in place or archive it according to your normal retention policy. Deleting that log is irreversible and is not required to undo the routing rule.