Hosting Operations
Read-only, can be slowFind the First Failure Line for One Unit
A failed service has repeated restart noise, and you need the earliest current-boot line that names an error or failed startup step.
Command
journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='
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 this as a complete log review; it intentionally stops at the first matching line and can miss later, more specific evidence.
Expected output
The earliest current-boot app error, failed step, or status line for the unit.
System impact
Read-only, can be slow. Nothing changes. journalctl prints the current-boot unit log and grep stops at the first matching failure line.
Scope this to the smallest useful path or service on busy systems.
Recovery / rollback: no state is changed.
When to use it
Use when restart loops bury the original clue under repeated systemd retry messages.
When not to use it
Do not use this as a complete log review; it intentionally stops at the first matching line and can miss later, more specific evidence.
Watch this command run
Command transcript
This sanitized transcript shows the commands and output shape without exposing host details.
$ journalctl -u app-worker -b --no-pager -o short-iso
2026-06-25T14:20:58-05:00 vps systemd[1]: Started app-worker.service - Background job worker.
2026-06-25T14:20:58-05:00 vps worker[2081]: loading /etc/app/worker.env
2026-06-25T14:20:58-05:00 vps worker[2081]: ERROR redis connection refused at localhost:6379
2026-06-25T14:20:59-05:00 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
2026-06-25T14:21:04-05:00 vps systemd[1]: app-worker.service: Scheduled restart job, restart counter is at 4.
2026-06-25T14:22:17-05:00 vps systemd[1]: Started app-worker.service - Background job worker.
2026-06-25T14:22:17-05:00 vps systemd[2144]: app-worker.service: Failed to determine user credentials: No such process
2026-06-25T14:22:17-05:00 vps systemd[2144]: app-worker.service: Failed at step USER spawning /srv/app/bin/worker: No such process
2026-06-25T14:22:17-05:00 vps systemd[1]: app-worker.service: Main process exited, code=exited, status=217/USER
2026-06-25T14:22:17-05:00 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
$ journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='
2026-06-25T14:20:58-05:00 vps worker[2081]: ERROR redis connection refused at localhost:6379
View commands shown
These are the commands shown in the sanitized transcript.
Commands shown
journalctl -u app-worker -b --no-pager -o short-isojournalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='
next steps
Related commands
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'
Read Warning and Error Logs for One Failed Unit
Filter a failed unit's journal to the lines most likely to explain the stop.
journalctl -u app-worker -b -p warning..alert --no-pager -n 80
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
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
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.
Useful for
- LPIC-1 style command-line practice
- LFCS style performance tasks
- Linux+ style troubleshooting review
Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.