Hosting Operations
Read-only, can be slowPrint a Critical Journal Timeline
You need a compact timeline of severe journal lines with timestamp, source, priority, and message.
Command
journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{print $1, $3, $4, substr($0,index($0,$5))}'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 it for full forensic retention; export logs through your normal incident process when needed.
Expected output
Timestamped severe log lines with source, priority, and message.
System impact
Read-only, can be slow. Nothing changes. The command prints a compact severe-event timeline.
Scope this to the smallest useful path or service on busy systems.
Recovery / rollback: no state is changed.
When to use it
Use when you need to compare app errors, worker exits, and supervisor messages in order.
When not to use it
Do not use it for full forensic retention; export logs through your normal incident process when needed.
Watch this command run
Command transcript
This sanitized transcript shows the commands and output shape without exposing host details.
$ journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso
2026-06-25T14:03:08+00:00 vps api[1842]: err request_id=req-103 ERROR database timeout after 30000ms
2026-06-25T14:03:12+00:00 vps api[1842]: err request_id=req-103 ERROR retry failed upstream=db
2026-06-25T14:05:10+00:00 vps worker[2201]: crit FATAL job runner exited code=137
2026-06-25T14:06:33+00:00 vps api[1842]: err request_id=req-107 ERROR payment provider returned 500$ journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{print $1, $3, $4, substr($0,index($0,$5))}'
2026-06-25T14:03:08+00:00 api[1842]: err request_id=req-103 ERROR database timeout after 30000ms
2026-06-25T14:03:12+00:00 api[1842]: err request_id=req-103 ERROR retry failed upstream=db
2026-06-25T14:05:10+00:00 worker[2201]: crit FATAL job runner exited code=137
2026-06-25T14:06:33+00:00 api[1842]: err request_id=req-107 ERROR payment provider returned 500View commands shown
These are the commands shown in the sanitized transcript.
Commands shown
journalctl -p err..alert --since "2 hours ago" --no-pager -o short-isojournalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{print $1, $3, $4, substr($0,index($0,$5))}'
next steps
Related commands
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
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'
Count App Errors by Minute
A minute-by-minute count shows whether an incident is a spike or a drip.
awk 'tolower($0) ~ /(error|fatal|timeout|exception)/ {minute=substr($1,1,16); count[minute]++} END {for (m in count) print count[m], m}' fixtures/incidents/app.log | sort -nr
Spot OOM Kills in the Kernel Journal
Exit code 137 often means the kernel has something to say.
journalctl -k --since "2 hours ago" --no-pager -o short-iso | grep -Ei 'out of memory|oom|killed process'
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.