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.
- 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.
- 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.
- 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.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
