Linux Survival Basics
Spot 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'What changed
Nothing changes. The command filters kernel journal lines for OOM evidence.
Danger
safe
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.
Undo or recovery
No undo needed because the command is read-only.
Expected output
Kernel journal lines mentioning out-of-memory or killed processes.
demo script
Disposable terminal steps
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'
simulated output
What it looks like
::fixture-ready::
$ 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
::exit-code::0
$ 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 worker
::exit-code::0
YouTube Short
Check for OOM kills.
If a process exits with 137, check the kernel journal. The app log may only show the symptom.
LinkedIn hook
Exit code 137 often means the kernel has something to say.
Question: When a worker exits with 137, do you check app logs or kernel logs first?
experiments
A/B tests to run
Metric: save_rate
A: Exit 137? Check kernel logs.
B: Find OOM kills fast.