systemctl commands: listing, restarting and checking services

Short answer: systemctl list-units --type=service lists every service systemd currently knows about and its state; systemctl restart NAME restarts one; journalctl -u NAME is the matching log command, not systemctl itself. The table below covers the commands people reach for most, with the real output of each one.

Listing services: list-units vs list-unit-files

These two commands answer different questions, and mixing them up is the most common confusion with systemctl:

systemctl list-units --type=service --no-pager

UNIT                      LOAD   ACTIVE SUB     DESCRIPTION
cron.service              loaded active running Regular background program processing daemon
nginx.service             loaded active running A high performance web server
ssh.service               loaded active running OpenBSD Secure Shell server

3 loaded units listed.

systemctl list-unit-files --type=service --no-pager

UNIT FILE                     STATE           PRESET
nginx.service                 enabled         enabled
mysql.service                 disabled        enabled
bluetooth.service             masked          enabled

list-units without --all hides inactive and dead units, so a service that exists but never started is invisible there; add --all to see it, or use list-unit-files directly, which always shows everything installed. STATE in the second table is the boot setting (enabled, disabled, static for a unit nothing enables directly, masked for one actively blocked from starting), not whether it is running right now.

systemctl status: reading the output

nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-10-14 08:02:11 UTC; 3h 12min ago
       Docs: man:nginx(8)
    Process: 612 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 701 (nginx)
      Tasks: 3 (limit: 4617)
     Memory: 5.2M
        CPU: 312ms
     CGroup: /system.slice/nginx.service
             ├─701 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─702 "nginx: worker process"
             └─703 "nginx: worker process"

Oct 14 08:02:11 vmheaven systemd[1]: Starting nginx.service - A high performance web server...
Oct 14 08:02:11 vmheaven systemd[1]: Started nginx.service - A high performance web server...

• Loaded shows the unit file’s path and whether it is enabled (will start at boot) — useful on its own, without a separate is-enabled call.
• Active is the real state: active (running) for a service with a running process, active (exited) for a one-shot job that finished successfully and stays “active”, failed when it crashed or exited with an error, inactive (dead) when it is simply stopped.
• The last lines are the newest journal entries for this unit — the same ones journalctl -u nginx shows, just the tail of them. Scroll with the pager (q to quit) or add --no-pager to print everything at once.

A failed service

Active: failed (Result: exit-code) since Tue 2026-10-14 11:04:02 UTC; 2min ago
Process: 1840 ExecStart=/usr/local/bin/myapp (code=exited, status=1/FAILURE)

systemctl --failed lists every unit in this state across the whole system in one call, which is the quickest way to notice something broke without checking each service by name. Reading past the exit code into what the program actually printed is in journalctl.

restart vs reload vs reload-or-restart

systemctl cat NAME prints the unit file itself, so systemctl cat nginx | grep ExecReload tells you directly whether a plain reload will work before you try it.

enable, disable and the boot-time confusion

start/stop act now; enable/disable change only what happens at the next boot. Running one without the other is the single most common systemctl mistake:

• systemctl start nginx alone: running now, but back off after a reboot if it was never enabled.
• systemctl enable nginx alone: will start at the next boot, but not running right now until you start it or reboot.
• systemctl enable --now nginx: both at once — the one to reach for after installing something new.

systemctl is-enabled nginx and systemctl is-active nginx answer the two questions separately and are the pair to use in a script, since both exit with status 0 only when the answer is yes.

systemctl has no log viewer — that is journalctl

systemctl status shows only the last handful of lines. For the full log of one service, everything since boot, or a live follow, the command is journalctl, covered in full in the journalctl guide:

systemctl status myapp          # quick look, last few lines
journalctl -u myapp              # the full log for this unit
journalctl -u myapp -f           # follow it live
journalctl -u myapp --since today

systemctl list-timers: systemd’s cron

NEXT                         LEFT       LAST                          PASSED  UNIT                     ACTIVATES
Wed 2026-10-15 03:00:00 UTC  11h left   Tue 2026-10-14 03:00:00 UTC   13h ago backup.timer             backup.service
Wed 2026-10-15 00:00:00 UTC  8h left    -                             -       apt-daily.timer          apt-daily.service

A timer unit (backup.timer) is paired with a service unit of the same name (backup.service) that actually runs the job; enable --now the timer, not the service, or the job only ever runs once, immediately. See creating a systemd service for writing both files, and crontab for the older cron-based way to schedule jobs that still works and is simpler for a single quick job.

systemctl --user: your own services, not root’s

Every command above manages the system instance by default. Add --user to manage services that run as your own login instead, with no sudo:

systemctl --user status myapp
systemctl --user enable --now myapp

A user service only keeps running while that user is logged in, unless you also run loginctl enable-linger yourname once as root. Run as root with sudo -u alice instead of a real login and it fails with Failed to connect to bus — systemctl --user --machine=alice@.host status reaches it from there instead.

When do I need systemctl daemon-reload?

Only after editing a unit file itself — /etc/systemd/system/myapp.service or a drop-in under myapp.service.d/ — never after changing the application’s own config file. Skipping it is why a change to a unit file sometimes seems to do nothing: systemd is still running the old definition from memory.

sudo systemctl daemon-reload
sudo systemctl restart myapp

systemctl: command not found

That error means the machine is not running systemd at all — a Docker container, a WSL distribution without systemd switched on, or Alpine’s OpenRC — and the fix there is the service manager that machine really has, not systemctl. The full decision tree for each case is in systemctl: command not found.

Frequently asked