systemctl — control systemd services

The one command that runs every service on a modern Linux box.

Your web server just died at 3am. The first command you type is systemctl status — and it tells you exactly what happened, when, and why. Here is how to read it like a pro.

What it does

systemctl is the front door to systemd, the init system that boots and supervises every service on virtually all modern Linux distributions. It starts, stops, restarts, enables, disables, and inspects units — services, sockets, timers, mounts. When something is broken, systemctl status is where you start looking.

Why it matters

Before systemd, every distro had its own init scripts and its own way of managing services. systemctl standardized it: the same commands work on Ubuntu, Fedora, Debian, and Arch. It also gives you dependency tracking, automatic restarts, and a unified log view via journalctl. If you administer any Linux server, systemctl is the command you will type more than any other.

Examples

systemctl status docker

● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-08-19 07:06:55 CEST; 2 weeks 0 days ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 2295363 (dockerd)
      Tasks: 355
     Memory: 1.3G (peak: 7.4G swap: 120.4M swap peak: 252.0M)

The Active line is the headline: active (running) since a date tells you it is up and when it started. Loaded shows whether it is enabled to start at boot.

systemctl is-active docker && systemctl is-enabled docker

active
enabled

is-active and is-enabled are script-friendly: they print one word and exit 0 on success, so you can chain them with && in cron jobs and health checks.

systemctl list-units --type=service --state=running

  UNIT                          LOAD   ACTIVE SUB     DESCRIPTION
  bolt.service                  loaded active running Thunderbolt system service
  containerd.service            loaded active running containerd container runtime
  cron.service                  loaded active running Regular background program processing daemon
  dbus.service                  loaded active running D-Bus System Message Bus
  docker.service                loaded active running Docker Application Container Engine
  fwupd.service                 loaded active running Firmware update daemon
  getty@tty1.service            loaded active running Getty on tty1

Filter to exactly what you want: running services only. Add --no-pager to avoid the pager when scripting.

systemctl restart nginx

$ systemctl restart nginx
$ systemctl is-active nginx
active

restart stops and starts a service in one step. No output on success — verify with is-active. This is the fix for a hung or misconfigured service.

systemctl list-timers

NEXT                             LEFT LAST                                    PASSED UNIT                           ACTIVATES
Wed 2026-09-02 09:10:00 CEST     8min Wed 2026-09-02 09:00:02 CEST      1min 30s ago sysstat-collect.timer          sysstat-collect.service
Wed 2026-09-02 09:56:10 CEST    54min Wed 2026-09-02 08:58:06 CEST      3min 26s ago fwupd-refresh.timer            fwupd-refresh.service
Wed 2026-09-02 11:12:43 CEST 2h 11min Tue 2026-09-01 03:40:53 CEST      1 day 5h ago plocate-updatedb.timer         plocate-updatedb.service

list-timers shows scheduled jobs (cron's modern replacement). NEXT and LEFT tell you when each will fire next.

Flags

Flag	Meaning
`status <unit>`	show whether a service is running, since when, and recent log lines
`start/stop/restart <unit>`	change a service's running state
`enable/disable <unit>`	set whether a service starts at boot
`is-active <unit>`	print active/inactive — script-friendly, exits 0 on active
`is-enabled <unit>`	print enabled/disabled — whether it starts at boot
`list-units`	list loaded units; filter with --type and --state
`list-timers`	show scheduled timer jobs and their next run times
`mask/unmask <unit>`	make a service impossible to start (hard disable)

Origin

systemd was created by Lennart Poettering in 2010 at Red Hat, and first shipped in Fedora in 2011. Its name is a play on the Unix daemon convention — the 'd' suffix — applied to the system itself. It replaced the SysV init scripts that had been the standard since the 1980s, and it was deeply controversial: the 'init wars' between systemd and its critics are still a live topic in the Linux community.

Fun fact

systemd does far more than start services. It also manages sockets, timers, device nodes, mount points, and even the login session. The name is a pun: it is the daemon that manages the system, so it is literally the 'system daemon' — systemd.

Fun facts

systemd's name is a pun: it is the daemon that manages the system, so it is literally the 'system daemon' — systemd.
systemd does far more than services: it manages sockets, timers, device nodes, mount points, and login sessions, which is why it is called an 'init system' but behaves like a whole operating-system layer.

Pros

One consistent interface across every major distro
Dependency tracking and automatic restarts built in
Unified with journalctl for logs — status shows recent output directly
Script-friendly is-active/is-enabled for automation

Cons

Steep learning curve — dozens of subcommands and unit types
Controversial; some admins still prefer the simpler SysV model
Overkill for trivial tasks that a shell script handled fine
Unit file syntax is finicky and easy to get wrong

Takeaways

Start debugging with `systemctl status <service>` — it shows state, uptime, and recent logs in one place
Use `systemctl restart <service>` to fix a hung or misconfigured service
Chain `systemctl is-active` in scripts — it exits 0 on active
enable starts at boot; start runs now — they are separate
Check scheduled jobs with `systemctl list-timers`, not just cron