systemctl: Start, Stop, Enable, Status

systemctl is your interface to systemd. If you administer Linux servers (or even a desktop), you’ll type these commands constantly. Five of them cover 95% of daily use.

The five essentials

sudo systemctl start nginx          # start a service now
sudo systemctl stop nginx           # stop it
sudo systemctl restart nginx        # stop + start
sudo systemctl reload nginx         # tell it to reload config (no restart)
sudo systemctl status nginx         # is it running? show recent logs

Auto-start on boot: enable / disable

sudo systemctl enable nginx         # start at next boot
sudo systemctl disable nginx        # don't start at boot
sudo systemctl enable --now nginx   # enable AND start now
sudo systemctl disable --now nginx  # disable AND stop now

systemctl is-enabled nginx          # check status
systemctl is-active nginx           # is it currently running

List services

systemctl list-units                       # all loaded units
systemctl list-units --type=service        # only services
systemctl list-units --state=failed        # things that crashed
systemctl list-unit-files                  # ALL unit files (loaded or not)
systemctl list-unit-files --state=enabled  # what's set to auto-start

Check what’s broken

systemctl --failed                    # quick look at failed services
systemctl status                      # overall system state
systemctl status nginx                # specific service status

systemctl status on a service shows: active/inactive, last few log lines, PID, memory usage, child processes. It’s the first command to run when “something’s not working.”

After editing a unit file

sudo systemctl daemon-reload       # tell systemd to reread unit files
sudo systemctl restart myapp       # apply the new unit file

The most common “I edited the unit file but nothing changed” cause: forgetting daemon-reload.

Mask: prevent a service from being started

sudo systemctl mask snapd          # cannot be started by anything
sudo systemctl unmask snapd        # undo

Useful when something is being auto-restarted and you don’t want it back.

Targets (like runlevels)

Targets are systemd’s grouping of services to reach a state.

systemctl get-default                          # current default target
sudo systemctl set-default multi-user.target   # boot to text mode
sudo systemctl set-default graphical.target    # boot to GUI

sudo systemctl isolate rescue.target           # switch to single-user now

User-level services

Services that run as YOU, not as root, with --user:

systemctl --user list-units
systemctl --user start mybot
systemctl --user enable mybot

User unit files live in ~/.config/systemd/user/.

Boot performance: what’s slow?

systemd-analyze                       # total boot time
systemd-analyze blame                 # which services took longest
systemd-analyze critical-chain        # critical path
systemd-analyze plot > boot.svg       # visual timeline

Useful “what services depend on what?” commands

systemctl list-dependencies nginx           # what nginx needs
systemctl list-dependencies --reverse nginx # what needs nginx
systemctl show nginx                         # ALL settings of the unit
systemctl cat nginx                          # show unit file contents

Daily one-liners

# Restart a service and immediately watch its logs
sudo systemctl restart nginx && sudo journalctl -fu nginx

# Show only services that aren't running but should be
systemctl --failed

# Quickly see status of a list of services
for svc in nginx php-fpm postgresql redis; do
  printf "%-20s %sn" "$svc" "$(systemctl is-active $svc)"
done

Common mistakes

• Forgetting daemon-reload after editing a unit file.
• Confusing start and enable: start = run now; enable = run at boot.
• Running systemctl status foo.service with sudo just to see status — sudo is only needed for changes.
• Using kill on a process systemd manages — systemd will just restart it. Use systemctl stop.

What to learn next

systemctl status shows you the recent log lines. To see the full history and search them, you need journalctl — the central log query tool. Up next.