systemd & Log-Driven Diagnosis

What is it?

systemd manages services, boot and dependencies; journalctl is its unified log. Log-driven diagnosis means letting the service state and its journal tell you what failed and why, in order.

Why it matters

When a service or boot fails, systemd already recorded the cause. Reading it beats guessing — the answer is usually in the last few journal lines.

Where you see it

`systemctl status <svc>`, `systemctl --failed`, `journalctl -u <svc> -p err`, `journalctl -b` (this boot), `systemd-analyze blame` (slow boot).

What normal looks like

All units active, no failed units, a clean boot, and dependencies starting in the right order.

What suspicious looks like

A unit in 'failed', a dependency that timed out, or a boot delayed by one slow unit — each named precisely by systemd.

How analysts investigate

Start at `systemctl --failed`, open the failed unit's status and journal, read the error and the dependency it needed, then fix the root and re-check — let the tool point the way.

Common beginner mistakes

Masking a failing unit instead of fixing why it fails.
Ignoring a dependency error and only restarting the top service.

Let systemd tell you

  systemctl --failed
    ● app.service   failed
  journalctl -u app.service -p err --since -10m
    app.service: Failed to open /etc/app/db.conf: Permission denied
  root cause: file perms/ownership → fix that, not the symptom

systemd names the failed unit; the journal names the reason — fix the root cause it points to.

Quick check

app.service failed; the journal says 'Permission denied' on its config. Right fix?

A quick self-check — it doesn't affect your XP or progress.