If your server process vanishes with no crash log, Linux probably killed it to save the system from running out of RAM — the "OOM killer". Here's how to confirm and prevent it, including the container-specific memory limits people forget about.
Quick answer
If your server process disappears with no crash log, the Linux OOM killer probably ended it to save RAM. Confirm with dmesg | grep -i "killed process". Then lower the process's memory use (for Java, keep -Xmx below the machine or container limit), add RAM or swap, and check container memory limits.
Confirm it was the OOM killer
Check the kernel log for the tell-tale message:
dmesg | grep -i 'killed process'
journalctl -k | grep -i oomA line like Out of memory: Killed process 1234 (java) confirms the kernel killed your server to free RAM.
Why it happens
The total RAM requested by everything on the box exceeded what's available. Common causes: a server allocated more than the machine has (e.g. -Xmx too high), too many servers on one box, or a memory leak.
| Cause | How to spot it | Fix |
|---|---|---|
| One server allocated too much | -Xmx near/over total RAM | Lower -Xmx, leave OS headroom |
| Too many servers on one box | Combined limits exceed RAM | Move one off, or upgrade the plan |
| A memory leak | RAM climbs steadily until the kill | Find and update the leaking app |
| Container memory limit hit | Killed well below host RAM | Raise the container/cgroup memory limit |
| No swap on a tight box | Kills on brief spikes | Add a small swap file as a buffer |
How to stop it
- Lower your allocation — leave 1–2 GB for the OS; never give a server all system RAM.
- Add swap — a few GB of swap absorbs spikes (slower, but prevents kills).
- Run fewer services per box, or move to a plan with more RAM.
- Find leaks — if usage only ever climbs, profile the app/plugins.
# add 4G of swap
fallocate -l 4G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfileThe OOM killer targets the process using the most memory — often your game server, even if a different process caused the spike. Fixing total RAM pressure is the real solution.
Confirm with dmesg, then leave headroom for the OS, add swap, and run within the RAM you actually have.
Container-specific memory limits
If your server runs in Docker or under a panel like Pterodactyl, a cgroup memory limit set on the container can trigger its own OOM kill independent of the host's total RAM — even if the host itself has plenty free. Check the container's configured memory limit, not just system-wide RAM — docker inspect shows a container's memory limit, and systemctl show shows a systemd service's MemoryMax.
How to prevent OOM kills for good
- Size
-Xmx(or the panel's RAM limit) comfortably below the container/host's actual memory, never equal to it. - Watch memory trend over days, not just a snapshot — a slow leak looks fine until it isn't.
- Set
vm.overcommit_memoryand swappiness sensibly rather than leaving kernel defaults untouched on a memory-constrained VPS.
Related errors
If the process fails to even start rather than being killed later, see fixing "cannot allocate memory" (fork failed). For Minecraft specifically running out of heap, see fixing Minecraft "out of memory" (Java heap space). To check usage generally, see how to check CPU, RAM and disk usage on Linux.