$ Linux One Liners
Back to lessons

Hosting Operations

Read Warning and Error Logs for One Failed Unit

A unit journal contains startup chatter, retries, and supervisor messages, and you need the warning-or-worse lines first.

Command

journalctl -u app-worker -b -p warning..alert --no-pager -n 80

What changed

Nothing changes. journalctl prints warning, error, critical, alert, and emergency entries for the unit.

Danger

safe

When to use it

Use after status when you need the likely failure lines without scrolling through every normal startup message.

When not to use it

Do not use severity filtering if the app logs important failures at info level; check the unfiltered unit journal too.

Undo or recovery

No undo needed because the command is read-only.

Expected output

Current-boot warning-or-worse journal lines for the failed service.

demo script

Disposable terminal steps

  1. journalctl -u app-worker -b --no-pager -n 80
  2. journalctl -u app-worker -b -p warning..alert --no-pager -n 80
Terminal transcript Demo JSON

simulated output

What it looks like

disposable vessel 
::fixture-ready::
$ journalctl -u app-worker -b --no-pager -n 80
Jun 25 14:20:58 vps systemd[1]: Started app-worker.service - Background job worker.
Jun 25 14:20:58 vps worker[2081]: loading /etc/app/worker.env
Jun 25 14:20:58 vps worker[2081]: ERROR redis connection refused at 127.0.0.1:6379
Jun 25 14:20:59 vps systemd[1]: app-worker.service: Main process exited, code=exited, status=1/FAILURE
Jun 25 14:20:59 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
Jun 25 14:21:04 vps systemd[1]: app-worker.service: Scheduled restart job, restart counter is at 4.
Jun 25 14:22:17 vps systemd[1]: Started app-worker.service - Background job worker.
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed to determine user credentials: No such process
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed at step USER spawning /srv/app/bin/worker: No such process
Jun 25 14:22:17 vps systemd[1]: app-worker.service: Main process exited, code=exited, status=217/USER
Jun 25 14:22:17 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
::exit-code::0
$ journalctl -u app-worker -b -p warning..alert --no-pager -n 80
Jun 25 14:20:58 vps worker[2081]: ERROR redis connection refused at 127.0.0.1:6379
Jun 25 14:20:59 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed to determine user credentials: No such process
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed at step USER spawning /srv/app/bin/worker: No such process
Jun 25 14:22:17 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
::exit-code::0

YouTube Short

Filter the failed unit journal.

After status, filter the current boot journal to warning and worse. It cuts noise while keeping the likely failure clues.

LinkedIn hook

Filter a failed unit's journal to the lines most likely to explain the stop.

Question: Do your services log real failures at warning or error level consistently?

experiments

A/B tests to run

Metric: average_view_duration

A: Filter journal noise first.

B: Warning and worse for one failed unit.