How to restart a service using systemctl
Restarting a service with systemctl replaces the running daemon process when a simple reload is not enough, which is common after binary updates, environment changes, stuck workers, or configuration changes that only take effect on a fresh start.
On a systemd host, systemctl restart unit.service asks the manager to stop the unit and then start it again. Current upstream behavior also starts the unit when it is inactive already, so a restart can bring a stopped service back online instead of failing as a no-op. A successful restart usually shows a new Main PID or a fresh since timestamp in systemctl status, and the unit journal records the stop/start sequence.
Because a restart briefly makes the service unavailable, it can drop active connections, interrupt jobs, or refuse new logins while the daemon comes back up. Run systemctl daemon-reload before the restart when the unit file or a drop-in changed, use reload or a service-specific reload path when the daemon supports rereading configuration in place, and use an explicit stop followed by start when a full teardown is required before the process returns.
Steps to restart a service using systemctl:
- Open a terminal on the host that runs systemd with an account that can use sudo.
Use systemctl --user restart unit.service instead of the system manager command when the target is a per-user service.
- Check the current service status before restarting it.
$ systemctl status --no-pager --full queue-worker.service ● queue-worker.service - Queue Worker Service Loaded: loaded (/etc/systemd/system/queue-worker.service; disabled; preset: enabled) Active: active (running) since Mon 2026-04-13 12:55:03 UTC; 11s ago Main PID: 147 (sleep) Tasks: 1 (limit: 14335) Memory: 160.0K (peak: 1.5M) CPU: 12ms CGroup: /system.slice/queue-worker.service └─147 /usr/bin/sleep infinity ##### snipped #####Replace queue-worker.service with the actual unit name, such as nginx.service, ssh.service, or postgresql.service. The status view confirms both the current runtime state and the unit file path before the restart.
- Record the current main PID when a clear before-and-after proof is needed.
$ systemctl show -p MainPID --value queue-worker.service 147
On most long-running services, a different MainPID after the restart confirms that systemd replaced the running process. Services that use Type=oneshot with RemainAfterExit=yes can legitimately report no long-running main process and still be healthy.
- Restart the service.
$ sudo systemctl restart queue-worker.service
Restarting a remote-access, proxy, database, or queue service can interrupt active clients immediately. Keep console or other out-of-band access available before restarting anything that might lock out the current session.
Current upstream systemctl behavior starts the unit if it is inactive already. Use sudo systemctl try-restart queue-worker.service when the service should restart only if it is already running.
- Confirm that the service came back active and, when applicable, that the main PID changed.
$ systemctl show -p MainPID --value queue-worker.service 179 $ systemctl is-active queue-worker.service active
A fresh MainPID or a new since timestamp in systemctl status shows that the service was stopped and started again instead of only reloading its configuration.
- Check the recent unit journal when the restart appears to succeed but the service falls back to failed or inactive.
$ sudo journalctl -u queue-worker.service -n 8 --no-pager Apr 13 12:55:19 server systemd[1]: Stopping queue-worker.service - Queue Worker Service... Apr 13 12:55:19 server bash[174]: queue-worker stopping Apr 13 12:55:19 server systemd[1]: queue-worker.service: Deactivated successfully. Apr 13 12:55:19 server systemd[1]: Stopped queue-worker.service - Queue Worker Service. Apr 13 12:55:19 server systemd[1]: Starting queue-worker.service - Queue Worker Service... Apr 13 12:55:19 server systemd[1]: Started queue-worker.service - Queue Worker Service. Apr 13 12:55:19 server bash[179]: queue-worker started
systemctl status already includes a few recent lines, but journalctl -u is the cleaner view when the stop hook hangs, the new process exits immediately, or the unit hits a dependency failure.
- Restart an inactive unit only when starting it again is acceptable.
$ sudo systemctl stop queue-worker.service $ systemctl is-active queue-worker.service inactive $ sudo systemctl restart queue-worker.service $ systemctl is-active queue-worker.service active
Because restart starts inactive units too, it is not a safe read-only test for whether a service was already running. Use systemctl is-active unit.service first when that distinction matters.
- Reload the systemd manager first when the service unit itself changed on disk.
$ sudo systemctl daemon-reload $ sudo systemctl restart queue-worker.service
daemon-reload makes systemd reread changed unit files and drop-ins. It does not restart the service by itself, so the follow-up restart still applies the new unit settings to the running process.