Verified8 commandsAI-assisted

systemd & journalctl

Verified against systemd 255, flags verified via `systemctl --help` / `journalctl --help`, 2026-08-20 · official docs

Managing services and reading their logs — the first two tools for "why did this service stop / why won't it start."

Service status and control#

systemctl status nginx
systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl reload nginx                        # re-read config without a full restart, if the service supports it

reload only works if the service's unit defines an ExecReload — many services fall back to a full restart if it doesn't, so check systemctl status output for whether reload actually did what you expected.

Enabling and disabling on boot#

systemctl enable nginx                         # start automatically on boot
systemctl disable nginx
systemctl is-enabled nginx
systemctl enable --now nginx                    # enable AND start in one command

enable/disable control boot-time startup; start/stop control the running state right now — they're independent. A service can be enabled but currently stopped, or running but not enabled (won't survive a reboot). A common on-call mistake is systemctl stop during an incident, without also disable, then being surprised it's back after the next reboot/deploy.

Listing and filtering units#

systemctl list-units --type=service --state=running
systemctl list-units --state=failed             # everything currently in a failed state
systemctl is-active nginx
systemctl is-failed nginx

Masking a unit (stronger than disable)#

systemctl mask nginx      # prevents starting even manually or as a dependency of another unit
systemctl unmask nginx

Reloading systemd after editing a unit file#

systemctl daemon-reload

Required any time you hand-edit a .service file — without it, systemd keeps using its in-memory copy of the old unit definition, and a restart will silently apply the old config.

Reading logs for a specific service#

journalctl -u nginx
journalctl -u nginx -f                          # follow/stream live
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx --since "2026-08-19 09:00" --until "2026-08-19 10:00"
journalctl -u nginx -n 100                       # last 100 lines

Filtering and searching logs#

journalctl -p err                                # priority filter: emerg/alert/crit/err/warning/notice/info/debug
journalctl -g "connection refused"                # grep the message field
journalctl -b                                     # logs since the current boot only
journalctl -k                                      # kernel messages (dmesg equivalent, from the journal)
journalctl -o json-pretty -u nginx -n 5            # structured output for piping into another tool

Managing journal disk usage#

journalctl --disk-usage
journalctl --vacuum-time=7d          # delete journal entries older than 7 days
journalctl --vacuum-size=500M         # shrink the journal to under 500MB

An unbounded journal is a real, recurring cause of a host quietly running out of disk — --vacuum-time/--vacuum-size are the direct fix; the durable fix is setting SystemMaxUse= in /etc/systemd/journald.conf so it never grows unbounded in the first place.