Reading systemd unit status and logs with journalctl for a beginner

2 min read

Something isn't running, or a cron job silently never fires, and the fix always starts the same way: check whether the service is actually enabled and running, then read what it logged. Two commands cover almost every case.

Step 1: is the service running at all?

systemctl status cron

Read the Active: line first — that's the answer to "is it running." Common states:

• active (running) — up and running normally.
• inactive (dead) — stopped. Start it with sudo systemctl start <name>.
• failed — it tried to start and crashed. The status output itself usually shows the last few log lines right below the Active: line, which is often enough to see why.
• Unit not found at all — the service isn't installed, or you have the wrong unit name. systemctl list-units --type=service lists everything currently loaded.

Also check Loaded: — specifically whether it says enabled or disabled. A service can be active (running) right now but disabled, meaning it won't come back after a reboot. sudo systemctl enable <name> fixes that separately from starting it.

Step 2: read what it actually logged

systemctl status only shows the last handful of lines. For the full picture:

journalctl -u cron              # all logs for this unit, oldest first
journalctl -u cron -f           # follow mode — like `tail -f`, watch it live
journalctl -u cron --since today
journalctl -u cron -n 50        # just the last 50 lines

-u <name> is the important flag — it filters to just that unit's logs instead of the entire system journal, which on a long-running machine can be huge.

Useful variations

journalctl -p err -u cron            # only error-level and above
journalctl -u cron --since "1 hour ago"
journalctl --disk-usage              # how much space the journal itself is using

What "no output" actually means

An empty journalctl -u <name> result is itself informative: it usually means either the unit has never run since the journal's retention window started, or you have the unit name slightly wrong (check with systemctl list-units | grep <partial-name>) — it does not generally mean "ran fine with nothing to report," since most services log at least a startup line.

The two-command habit

For "why isn't X working" on anything managed by systemd, systemctl status <name> then journalctl -u <name> -n 50 covers the majority of cases before reaching for anything more specialized — config file syntax checks, permission issues, etc.

Sources: man systemctl, man journalctl; verified directly against a real cron service status check while building this project's automation.