How to reload a service using systemctl

Reloading a service with systemctl applies supported application configuration changes without tearing down the running process tree completely. This is useful when the daemon can reread its own config in place and a full restart would interrupt connections, discard in-memory state, or create an avoidable service gap.

On a systemd host, systemctl reload unit.service does not reread the unit file itself. It asks the service to run its configured reload path, typically through ExecReload= or Type=notify-reload, and current upstream systemctl and systemd.service documentation treats that as separate from systemctl daemon-reload, which only makes the manager reread unit definitions from disk.

Examples below use a generic reload-demo.service unit name to show a reload-capable service. Replace it with the real unit name on the host, add sudo for system services, and use systemctl --user for per-user units. Check reload support before using the command, because a unit that reports CanReload=no fails immediately, and a unit-file or drop-in change still needs systemctl daemon-reload plus the appropriate follow-up lifecycle action.

Steps to reload a service using systemctl:

Open a terminal on the host that runs systemd and confirm that the target unit supports a live reload.
```
$ systemctl show -p CanReload reload-demo.service
CanReload=yes
```
Replace reload-demo.service with the actual unit name, such as nginx.service, dbus.service, or another service that documents an in-place reload path.

When CanReload=no, an attempted reload fails with a message such as Failed to reload cron.service: Job type reload is not applicable for unit cron.service.

Related: How to manage a service using systemctl
Run the reload command for the service.
```
$ sudo systemctl reload reload-demo.service
```
Use systemctl --user reload unit.service for a per-user service instead of the system manager.

systemctl reload asks the running service process to reread its own configuration. It does not make systemd reread the unit file or drop-in overrides.

When the change was made to the unit file itself under /etc/systemd/system, /run/systemd/system, or a *.d override, use systemctl daemon-reload first and then start, restart, or reload the service as needed.

Related: How to reload the systemd manager configuration

Check the human-readable service status after the reload so the unit stays active and the reload action appears in the service metadata.

$ systemctl status --no-pager --full reload-demo.service
● reload-demo.service - Reload demo service
     Loaded: loaded (/etc/systemd/system/reload-demo.service; disabled; preset: enabled)
     Active: active (running) since Mon 2026-04-13 20:58:54 +08; 2s ago
    Process: 1527 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
   Main PID: 1512 (bash)
      Tasks: 2 (limit: 4543)
     Memory: 736.0K (peak: 1.2M)
        CPU: 3ms
     CGroup: /system.slice/reload-demo.service
             ├─1512 bash /usr/local/bin/reload-demo.sh
             └─1514 sleep 300

Apr 13 20:58:54 host systemd[1]: Started reload-demo.service - Reload demo service.
Apr 13 20:58:56 host systemd[1]: Reloading reload-demo.service - Reload demo service...
Apr 13 20:58:56 host systemd[1]: Reloaded reload-demo.service - Reload demo service.

The Active: line should stay active (running) for a long-lived service. The extra Process: line for ExecReload= shows that the reload hook ran without a full restart.

Read the recent journal when the status output is trimmed, the service reported an error, or the application still behaves like it is using the old configuration.
```
$ sudo journalctl -u reload-demo.service -n 6 --no-pager
Apr 13 20:58:54 host systemd[1]: Started reload-demo.service - Reload demo service.
Apr 13 20:58:56 host systemd[1]: Reloading reload-demo.service - Reload demo service...
Apr 13 20:58:56 host systemd[1]: Reloaded reload-demo.service - Reload demo service.
```
systemctl status already shows a few recent lines, but journalctl -u is the clearer follow-up when you need the exact reload transaction or a failure reason from the daemon.

Related: How to view system logs using journalctl
Related: How to check service status using systemctl
Use a restart instead when the unit does not support reload or the daemon documentation says the changed setting is only read at process start.
```
$ sudo systemctl restart reload-demo.service
```
Reload support is optional. A service with no reload path cannot be forced to reread its application configuration through systemctl reload alone.

Related: How to manage a service using systemctl