A process vanishes. No crash log, no error — it was just there, and now it isn't. Nine times out of ten on a memory-starved box, the OOM killer did it: when Linux runs out of memory, the kernel picks a process and kills it to save the system. Here's how to confirm it and stop it recurring.
Why it exists
Linux lets processes allocate more memory than physically exists (overcommit), betting they won't all use it at once. When that bet fails and memory truly runs out, something has to give — so the kernel's OOM killer scores every process and terminates the one with the highest oom_score (roughly: biggest memory hog) to keep the box alive.
Confirm it was the OOM killer
The smoking gun is in the kernel ring buffer and the journal:
dmesg -T | grep -i -E 'killed process|out of memory' journalctl -k --since "30 min ago" | grep -i oom # "Out of memory: Killed process 4242 (java) total-vm:..."
That line names the PID and process it sacrificed. If the thing that "crashed" is in that log, you're not debugging a crash — you're debugging memory pressure.
Find what's eating the memory
free -h for the overall picture, then ps aux --sort=-%mem | head to rank processes by memory. A steadily climbing number over time is a leak; a sudden spike is usually a workload that needs limiting.
Stop it happening again
Pick the real fix, not just a reboot: add RAM or swap, cap the offender with a systemd MemoryMax= or a container memory limit, fix the leak, or tune vm.swappiness. Killing or restarting the process (see kill vs kill -9) clears the symptom; the memory ceiling is the cause.
Practise surviving memory pressure
OOM kills and memory-leak incidents show up in the simulator's Chaos Engine. Drill the confirm-then-cure loop with Linux troubleshooting practice and see the wider family in common Linux incidents.