Linux Survival Basics
Read-only, can be slowSpot OOM Kills in the Kernel Journal
A worker exited during an incident and you need to check whether the kernel killed it for memory pressure.
Command
journalctl -k --since "2 hours ago" --no-pager -o short-iso | grep -Ei 'out of memory|oom|killed process'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 as a full memory diagnosis; follow up with memory, swap, cgroup, and process checks.
Expected output
Kernel journal lines mentioning out-of-memory or killed processes.
System impact
Read-only, can be slow. Nothing changes. The command filters kernel journal lines for OOM evidence.
Scope this to the smallest useful path or service on busy systems.
Recovery / rollback: no state is changed.
When to use it
Use when services exit with code 137, restart suddenly, or disappear under memory pressure.
When not to use it
Do not use it as a full memory diagnosis; follow up with memory, swap, cgroup, and process checks.
Watch this command run
Command transcript
This sanitized transcript shows the commands and output shape without exposing host details.
$ journalctl -k --since "2 hours ago" --no-pager -o short-iso
2026-06-25T14:05:09+00:00 vps kernel: warning Memory cgroup out of memory: Killed process 2201 worker total-vm:512000kB
2026-06-25T14:05:10+00:00 vps kernel: err oom_reaper: reaped process 2201 worker$ journalctl -k --since "2 hours ago" --no-pager -o short-iso | grep -Ei 'out of memory|oom|killed process'
2026-06-25T14:05:09+00:00 vps kernel: warning Memory cgroup out of memory: Killed process 2201 worker total-vm:512000kB
2026-06-25T14:05:10+00:00 vps kernel: err oom_reaper: reaped process 2201 workerView commands shown
These are the commands shown in the sanitized transcript.
Commands shown
journalctl -k --since "2 hours ago" --no-pager -o short-isojournalctl -k --since "2 hours ago" --no-pager -o short-iso | grep -Ei 'out of memory|oom|killed process'
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
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))}'
Read Current-Boot Logs for One Service
Ignore stale logs and inspect only what happened since this boot.
journalctl -u nginx -b --no-pager -n 80
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'
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.