Back to commands

Hosting Operations

Read-only, can be slow

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

Before you run this

System impact: Read-only. Can create load on large logs, directories, filesystems, or process tables.

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.

Expected output

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

System impact

Read-only, can be slow. Nothing changes. journalctl prints warning, error, critical, alert, and emergency entries for the unit.

Scope this to the smallest useful path or service on busy systems.

Recovery / rollback: no state is changed.

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.

next steps

Related commands

Hosting Operations Can be slow

Find the First Failure Line for One Unit

The first failure line is often more useful than the last restart message.

journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='

Hosting Operations Can be slow

Build a Restart Loop Timeline

Restart loops make more sense when you line up starts, failures, and counters.

journalctl -u app-worker -b --no-pager -o short-iso | grep -E 'Started|Failed|Scheduled restart|Main process exited'

Hosting Operations Can be slow

Summarize Journal Severity During an Incident

Start with severity counts before opening every log line.

journalctl -p warning..alert --since "2 hours ago" --no-pager -o short-iso | awk '{count[$4]++} END {for (level in count) print count[level], level}' | sort -nr

Hosting Operations Can be slow

Group Journal Errors by Unit

A noisy incident usually has a noisy source.

journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{split($3,a,"["); unit=a[1]; count[unit]++} END {for (u in count) print count[u], u}' | sort -nr

Hosting Operations Can be slow

Print a Critical Journal Timeline

Timeline beats guesswork when several failures happen close together.

journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{print $1, $3, $4, substr($0,index($0,$5))}'

Study mapping

Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.

Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.