How to reload or restart a service using systemctl

The systemctl reload-or-restart verb is useful after an application configuration change when a live reload is preferred, but the target service might not implement one. It lets you issue one command during maintenance, deploys, or routine config changes instead of guessing whether the unit needs a reload or a full restart.

Current upstream systemctl documentation states that reload-or-restart reloads units that support reload, stops and starts units that do not, and starts inactive units when they are not running yet. In practice, CanReload= from systemctl show is the quick preflight check, and a follow-up status or journal check shows whether systemd used the reload path or a restart fallback.

This command affects the running service process, not systemd's in-memory copy of unit definitions. If you edited a unit file or drop-in under /etc/systemd/system, run sudo systemctl daemon-reload first. Add sudo for system services, use systemctl --user reload-or-restart for per-user units, and switch to try-reload-or-restart instead when you want the command to act only on units that are already active.

Steps to reload or restart a service using systemctl:

Check whether the target unit is running and whether it supports a live reload before using the combined command.
```
$ systemctl show -p ActiveState -p SubState -p CanReload reload-demo.service
ActiveState=active
SubState=running
CanReload=yes

$ systemctl show -p ActiveState -p SubState -p CanReload restart-demo.service
ActiveState=active
SubState=running
CanReload=no
```
Replace reload-demo.service or restart-demo.service with the real unit name on the host. When CanReload=yes, systemd can ask the service to reread its own configuration in place. When CanReload=no, reload-or-restart falls back to a stop-and-start cycle.

Current upstream systemd.service guidance recommends a synchronous reload path, typically through ExecReload= or Type=notify-reload. Units without one of those mechanisms commonly report CanReload=no.

Run reload-or-restart when the service supports reload and you want to preserve the running process where possible.

$ sudo systemctl reload-or-restart reload-demo.service

$ systemctl status --no-pager --full reload-demo.service | sed -n '1,7p'
* reload-demo.service - Reload Demo Service
     Loaded: loaded (/etc/systemd/system/reload-demo.service; static)
     Active: active (running) since Mon 2026-04-13 12:56:23 UTC; 36s ago
    Process: 431 ExecReload=/bin/kill -USR1 $MAINPID (code=exited, status=0/SUCCESS)
   Main PID: 377 (reload-demo.sh)
      Tasks: 2 (limit: 14335)

The same MainPID before and after the command, plus the populated ExecReload result, shows that systemd reloaded the service instead of restarting it.

Use the same command on a service that does not implement reload when you want systemd to fall back to a full restart automatically.
```
$ systemctl show -p MainPID -p CanReload restart-demo.service
MainPID=382
CanReload=no

$ sudo systemctl reload-or-restart restart-demo.service

$ systemctl show -p MainPID -p CanReload restart-demo.service
MainPID=434
CanReload=no
```
The changed MainPID proves that systemd stopped and started the service because the unit could not reload itself in place.

The restart path can interrupt in-flight work or client connections. If downtime is not acceptable, confirm the service's reload support and service-specific graceful-reload behavior before using the combined command on production units.

Related: How to restart a service using systemctl
Expect an inactive unit to start when you run reload-or-restart against it.
```
$ sudo systemctl stop restart-demo.service

$ systemctl is-active restart-demo.service
inactive

$ sudo systemctl reload-or-restart restart-demo.service

$ systemctl is-active restart-demo.service
active
```
Current upstream systemctl documentation states that inactive units are started by reload-or-restart. Use sudo systemctl try-reload-or-restart unit.service instead when the command should act only on units that are already running.

Unit-file edits are a different workflow. After changing a /etc/systemd/system/*.service/ file or drop-in, run sudo systemctl daemon-reload first, then use reload-or-restart only if the service itself needs new application settings applied.

Related: How to reload the systemd manager configuration