journalctl -u: Read a Service’s Logs in CI
journalctl -u <unit> shows the journal entries for a single systemd service, oldest first.
Once systemctl tells you a unit failed, journalctl tells you why. Scope it to the unit and a time window so you are not scrolling the whole machine’s log.
What it does
journalctl reads the systemd journal. With -u it filters to one unit, -n limits the line count, -f follows new lines live, and -p err filters by priority. Output is paged unless you pass --no-pager.
Common usage
journalctl -u docker --no-pager -n 100
journalctl -u docker -f # follow live
journalctl -u myapp --since "10 min ago" -p err
journalctl -u myapp -o cat # message text only, no timestampsOptions
| Flag | What it does |
|---|---|
| -u <unit> | Show entries for one unit |
| -n <N> | Show the last N lines |
| -f | Follow new entries as they arrive |
| -p <level> | Filter by priority (err, warning, info, debug) |
| --since / --until | Time window, e.g. "10 min ago" or "today" |
| -o cat | Print only the message, no metadata |
| --no-pager | Do not page output (required in CI) |
In CI
Use journalctl -u <unit> --no-pager -n 200 in a failure step to capture why a dependency died. Never use -f in a non-interactive job; it follows forever and the step never returns.
Common errors in CI
"No journal files were found." means the journal is volatile and empty (common in containers) or your user lacks access; run with sudo or add the user to the systemd-journal group. "Failed to add match ‘-u’" means you put -u after the unit name; flags come first. If output is empty, the unit may log to stdout/stderr captured by Docker rather than the journal.