How to manage the syslog service

Managing the rsyslog service is the handoff between changed logging rules and the daemon that actually receives, routes, and writes messages. Checking the unit state before and after each action prevents a restart, stop, or reload attempt from being mistaken for a working logging path.

On systemd hosts, the packaged unit is normally rsyslog.service, with syslog.service kept as an alias on current Ubuntu packages. The normalized systemctl show fields make service checks easier to compare than the long status view, and CanReload tells whether a plain reload action is supported by the installed unit.

Current Ubuntu 26.04 packages report CanReload=no for rsyslog.service, so use restart after validated configuration changes or reload-or-restart when a mixed fleet may include units that do support reload. Stopping the service can leave syslog.socket active, so verify the final state explicitly and do not treat a stopped service as a persistent disablement decision.

Steps to manage the rsyslog service:

Open a terminal session on the Linux host with an account that can use sudo.

These commands require a systemd-managed service. Minimal containers, rescue shells, and some WSL environments may not have a running system manager.
Check the loaded unit, boot state, active state, and reload support before changing anything.
```
$ sudo systemctl show rsyslog --property=LoadState,UnitFileState,ActiveState,SubState,CanReload
LoadState=loaded
ActiveState=active
SubState=running
UnitFileState=enabled
CanReload=no
```
rsyslog.service is the service unit name. Current Ubuntu packages also install syslog.service as an alias, but using rsyslog keeps the command tied to the actual daemon.
Start rsyslog when the service is inactive.
```
$ sudo systemctl start rsyslog
$ sudo systemctl show rsyslog --property=ActiveState,SubState
ActiveState=active
SubState=running
```
A successful systemctl start command usually prints no output. The follow-up state check is the proof that the daemon is running.
Restart rsyslog after a validated configuration change.
```
$ sudo systemctl restart rsyslog
$ sudo systemctl show rsyslog --property=ActiveState,SubState,MainPID,CanReload
ActiveState=active
SubState=running
CanReload=no
MainPID=109
```
Run the rsyslog syntax check before restarting after a rule or drop-in change. A restart applies the new configuration to the live daemon, while a syntax check catches parser errors first.

Related: How to test rsyslog configuration syntax
Use reload-or-restart when the same command must work on hosts with different reload support.
```
$ sudo systemctl reload-or-restart rsyslog
$ sudo systemctl show rsyslog --property=ActiveState,SubState,MainPID,CanReload
ActiveState=active
SubState=running
CanReload=no
MainPID=131
```
When CanReload=no, systemctl reload-or-restart rsyslog restarts the service. When CanReload=yes on another distribution or custom unit, it asks the service to reload instead.
Avoid plain reload unless the unit reports reload support.
```
$ sudo systemctl reload rsyslog
Failed to reload rsyslog.service: Job type reload is not applicable for unit rsyslog.service.
```
This failure means the unit has no reload job type; it is not by itself proof that the rsyslog configuration is broken. Use restart or reload-or-restart for the current Ubuntu unit.
Stop rsyslog only when the maintenance or troubleshooting task requires it.
```
$ sudo systemctl stop rsyslog
Stopping 'rsyslog.service', but its triggering units are still active:
syslog.socket
$ sudo systemctl show rsyslog --property=ActiveState,SubState
ActiveState=inactive
SubState=dead
```
Local syslog routing changes while rsyslog is stopped. On systems with an active syslog.socket trigger, later writes to the syslog socket may start the service again.

Start the service again after the maintenance window or receiver test.

$ sudo systemctl start rsyslog
$ sudo systemctl show rsyslog --property=ActiveState,SubState,MainPID
ActiveState=active
SubState=running
MainPID=160

Inspect the service status and recent unit journal when an action fails.
```
$ sudo systemctl status rsyslog --no-pager
$ sudo journalctl --unit=rsyslog --no-pager --since "15 minutes ago"
```
systemctl status shows whether the unit is loaded, active, failed, or triggered by another unit. journalctl shows recent service messages when the local journal has retained entries for the selected time window.

Related: How to troubleshoot missing syslog messages