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.

1. 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.

2. 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.

   Related: How to reload a service using systemctl
   Related: How to check service status using systemctl

3. 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

4. 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