Linux · high · Core system faults

A process is killed by the OOM killer

The kernel ran out of memory and killed the process with the highest badness score to keep the system alive.

What you see

A service disappears with no error of its own. dmesg records an out-of-memory kill. Under systemd the unit shows result 'oom-kill' or signal SIGKILL; in a container the exit code is 137.

What is actually wrong

Genuine memory exhaustion, a leak, no swap on a machine sized as though it had some, or a cgroup memory limit set lower than the workload needs.

Codes and articles

Out of memory: Killed processoom-killoom_reaperKilledexit code 137

Fixes (2)

Confirm the kill and find what consumed the memory

Shell30 minuteslow riskreversible

The process runs directly on the host.

Confirm it was the OOM killer and see what it chose.
Shell
```
sudo dmesg -T | grep -i -A3 'out of memory'sudo journalctl -k -g 'Out of memory' --no-pager
```
The kernel prints a table of every process and its RSS at the moment of the kill, which is the best evidence you will get of what was actually using the memory.
Look at current usage including how much is genuinely available.
Shell
```
free -hps aux --sort=-%mem | head -15
```
The 'available' column is the one that matters — 'free' looks alarmingly low on a healthy Linux box because the kernel uses spare memory for cache.
Check whether there is any swap at all.
Shell
```
swapon --showcat /proc/sys/vm/swappiness
```

Add swap if there is none. It does not prevent OOM but it turns a hard kill into slow degradation you can react to.

Shell

sudo fallocate -l 4G /swapfilesudo chmod 600 /swapfilesudo mkswap /swapfilesudo swapon /swapfileecho '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Protect the important process by lowering its OOM score, so something else is chosen instead.
Shell
```
sudo systemctl edit myservice.service
```
Add OOMScoreAdjust=-500 under [Service]. This is a trade, not a fix — something still gets killed.
Deal with the real cause: fix the leak, cap the application's own memory settings, or add RAM.

Confirm it workedThe workload runs without further OOM events.

Shell

sudo journalctl -k -g 'Out of memory' --since '1 hour ago' --no-pager

If you need to undo itswapoff /swapfile and remove the fstab line; systemctl revert myservice.service.

Raise or correct the cgroup memory limit

Shell20 minuteslow riskreversible

The process is in a container or a systemd unit with MemoryMax set. The host may have plenty of free memory — the limit is local to the cgroup.

Read the current limit and peak usage for the unit.

Shell

systemctl show myservice.service -p MemoryMax -p MemoryHigh -p MemoryPeaksystemd-cgtop -m --iterations=1

For a container, read the limit from the runtime.

Shell

docker inspect -f '{{.HostConfig.Memory}}' mycontainerdocker stats --no-stream mycontainer

Raise it, or set MemoryHigh below MemoryMax so the process is throttled and reclaimed before it is killed.
Shell
```
sudo systemctl set-property myservice.service MemoryHigh=3G MemoryMax=4G
```
MemoryHigh applies back-pressure and reclaims; MemoryMax is the hard wall where the kill happens. Having only MemoryMax means going from fine to killed with nothing in between.

Reload and restart.

Shell

sudo systemctl daemon-reload && sudo systemctl restart myservice.service

Confirm it workedThe service stays up under its normal load.

Shell

systemctl show myservice.service -p MemoryPeak -p MemoryMax

If you need to undo itsudo systemctl revert myservice.service

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.