The systemctl command in Linux
systemctl is the interface to systemd, the init system of virtually all current distributions. Services (nginx, postgres, your own apps) are "units"; systemctl starts and stops them now, enables them at boot, and reports their status — including the last log lines, which makes systemctl status the first stop when anything misbehaves.
How systemctl works
systemctl is a client: the work happens in systemd (PID 1), reached over D-Bus. Units — services, timers, mounts, sockets — are declarative files describing what to run and what it depends on; systemd computes the dependency graph and orders operations, which is how enabling one service transparently pulls in what it needs.
systemd's superpower is cgroups: every process a service spawns, including forks of forks, lives in the service's control group. That is why "systemctl stop" is reliable where old init scripts leaked orphans — the whole group is terminated — and why status can list every process belonging to a service and account for its memory and CPU precisely.
Syntax
systemctl COMMAND [UNIT]Common options
| Option | What it does |
|---|---|
status UNIT | State, PID, uptime, and recent log lines — the diagnostic starting point. |
start / stop / restart | Control the service now. |
reload | Re-read configuration without a full restart (if the unit supports it). |
enable / disable | Start (or not) automatically at boot. enable --now also starts it immediately. |
list-units --type=service | Everything currently loaded. |
daemon-reload | Re-read unit files after you edit them. |
How to use systemctl: examples
$ systemctl status nginxIs it running, since when, with what PID — and the last few log lines.
$ sudo systemctl restart myappThe deploy-day classic.
$ sudo systemctl enable --now postgresqlStart now AND at every boot, in one command.
$ systemctl list-units --type=service --state=failedAnything red on this machine?
$ sudo systemctl daemon-reloadAfter editing a unit file — systemd caches them.
Real-world use cases for systemctl
Shipping your own service
Any long-running script deserves a unit file: ten lines in /etc/systemd/system/myapp.service (ExecStart, Restart=on-failure, User=), then daemon-reload and enable --now. You gain supervised restarts, boot persistence and journald logging — retirement papers for nohup-in-a-screen deployments.
The morning-after audit
After patching night: systemctl list-units --state=failed on each host. Empty output is the all-clear; anything listed comes with systemctl status ready to show why. Two commands, complete confidence.
Pro tips and common mistakes
- status is diagnosis, not just state: PID, uptime, memory and the last log lines in one screen. Read it before journalctl.
- Edited a unit file? Nothing happens until daemon-reload — systemd caches units, and forgetting this is the classic "my change was ignored".
- enable --now exists so you stop forgetting one half of the enable/start pair.
Frequently asked questions about systemctl
restart or reload?
restart stops and starts (brief downtime, drops connections). reload asks the service to re-read config gracefully — prefer it when the service supports it (nginx does).
enable vs start?
start affects now; enable affects boot. A started-but-disabled service dies at reboot — the classic "it worked until the maintenance window" story.
Where do my service logs go?
Into the journal: journalctl -u myservice. systemd captures stdout/stderr of units automatically.
Related commands
See what is running, find a process ID, and combine with grep to hunt down a program.
killTerminate processes politely or forcibly — and understand what -9 really does.
journalctlQuery the system journal: by service, time window, priority — and follow live.