Guide Linux Intermediate

systemd & Service Commands

systemctl and journalctl — the everyday commands for starting, stopping, enabling, and reading logs for services managed by systemd.

3 min read
linuxcommandssystemdsystemctl

Managing a Service: systemctl

sudo systemctl start nginx        # start now
sudo systemctl stop nginx           # stop now
sudo systemctl restart nginx          # stop then start
sudo systemctl reload nginx             # reload config without dropping connections (if the service supports it)
sudo systemctl status nginx               # current state + last log lines

sudo systemctl enable nginx        # start automatically on future boots
sudo systemctl disable nginx         # don't start automatically
sudo systemctl enable --now nginx      # enable AND start in one command
sudo systemctl is-active nginx           # just prints "active" or "inactive"
sudo systemctl is-enabled nginx            # just prints "enabled" or "disabled"

Listing Units

systemctl list-units --type=service              # all loaded service units
systemctl list-units --type=service --state=running
systemctl list-units --failed                      # anything that failed to start
systemctl list-unit-files --type=service            # every known service unit and its enabled state
systemctl list-timers                                 # all scheduled timers (systemd's cron)

Editing & Reloading Unit Definitions

sudo systemctl edit nginx              # create a drop-in override without touching the original unit file
sudo systemctl edit --full nginx         # edit the full unit file directly
sudo systemctl daemon-reload               # REQUIRED after any manual unit file edit — reloads systemd's in-memory config

Targets (Runlevels)

systemctl get-default              # default boot target (e.g., multi-user.target)
sudo systemctl set-default multi-user.target   # change the default target
sudo systemctl isolate rescue.target             # switch to rescue mode right now (be careful — stops most services)
systemctl list-dependencies multi-user.target      # what a target actually brings up

Reading Logs: journalctl

journalctl -u nginx                  # all logs for one unit
journalctl -u nginx -f                 # follow live (like tail -f)
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -p err               # only error-level or worse
journalctl -b                              # logs since the current boot
journalctl -b -1                             # logs from the PREVIOUS boot
journalctl -k                                  # kernel messages only
journalctl --disk-usage                          # how much space the journal is consuming
sudo journalctl --vacuum-time=7d                    # trim the journal to the last 7 days

Analyzing Boot & Startup Time

systemd-analyze                    # total time to boot
systemd-analyze blame                # which units took the longest to start, ranked
systemd-analyze critical-chain         # the critical dependency path that determined boot time

Timers: systemd’s Cron Replacement

systemctl list-timers                     # every scheduled timer + next run time
sudo systemctl enable --now backup.timer     # enable and start a timer
sudo systemctl start backup.service            # manually trigger the associated service right now, ignoring the schedule

Production Considerations

  • Forgetting systemctl daemon-reload after editing a unit file is one of the most common “why didn’t my change take effect” issues — systemd keeps using the old definition until reloaded.
  • Prefer systemctl edit (drop-in overrides) over editing vendor-shipped unit files directly — package upgrades won’t silently overwrite your customizations.
  • systemctl status output truncates logs — for real investigation, go straight to journalctl -u <service> --since ... with a proper time range.

Quick Interview Answer

“systemctl start/stop/restart/reload manage a service’s running state, enable/disable control whether it starts at boot, and status gives a quick health check. journalctl -u <service> reads that service’s logs, -f follows live, and -b -1 reaches back to the previous boot after an unexpected reboot. Any manual unit file edit needs systemctl daemon-reload before it takes effect.”

Common Mistakes

  • Editing a .service file and forgetting daemon-reload, then being confused why nothing changed.
  • Editing the original unit file shipped by a package instead of using systemctl edit for an override, losing customizations on the next update.
  • Relying only on systemctl status’s truncated log tail instead of querying journalctl properly during an incident.

Add More Questions to This Guide

Know a question that should be here? Share it and help the community!

Open Google Form