The operating system killed the server for using too much memory
What it looks like in your log
Minecraft server exited with code 137
What causes it
The process was killed from outside Java (exit 137, the OOM killer). Heap plus everything Java allocates outside the heap grew past the machine or container limit, so the log just stops with no Java error and no crash report.
How to fix it
Size the heap against what is left, not against the limit. Outside -Xmx, Java also needs class metadata, compiled code, direct network buffers, garbage-collector structures, thread stacks and C allocator arenas, which together run to roughly 1.5 to 2.5 GB on a large modpack and a few hundred megabytes on a plugin server. Leave that much clear above -Xmx, and cap the open-ended parts with -XX:MaxMetaspaceSize, -XX:MaxDirectMemorySize and -XX:ReservedCodeCacheSize so an overrun becomes a named Java error you can read instead of a silent kill.
Why it happens
Exit code 137 is 128 plus signal 9: the operating system sent SIGKILL. Java did not crash, it was executed. On a container or a VPS that almost always means the cgroup memory limit was hit and the kernel picked the biggest process, which is always the server. There is no Java error, no crash report and no goodbye in the log, because Java never got a chance to write one.
The trap is that the heap fit. -Xmx was under the limit, so the owner assumes memory was fine. But the heap is only part of what a Java process uses. Class metadata, compiled code, thread stacks, direct network buffers, garbage collector bookkeeping and the C allocator all live outside -Xmx, and on a large modpack they add up to 1.5 to 2.5 GB. A 10 GB heap on a 12 GB container will get killed.
Fix it step by step
- 1Confirm it was the kernelOn your own machine, dmesg or journalctl -k will show "Out of memory: Killed process ... (java)". On a hosted panel, the log ending without a Java error and the last line being an exit code or a restart is the same evidence.
- 2Lower -Xmx, do not raise itLeave headroom above the heap for everything else Java allocates. On a modpack with hundreds of mods leave 2 GB; on a plugin server leave 500 MB to 1 GB. On a hosted plan, keep -Xmx to about four fifths of the plan.
- 3Cap the open-ended poolsAdd -XX:MaxMetaspaceSize, -XX:MaxDirectMemorySize and -XX:ReservedCodeCacheSize so an overrun in one of them becomes a named Java error you can read instead of a silent kill. The defaults are unbounded on purpose; on a memory-limited machine that is the wrong default.
- 4Drop AlwaysPreTouch on a tight box-XX:+AlwaysPreTouch commits the whole heap at start-up, which is fine with headroom and lethal without it. If your flags include it and the container is tight, remove it.
- 5Watch the process, not the heapThe number that matters is resident set size of the whole process, which the panel memory graph or ps shows. If it climbs to the limit over hours with the heap flat, a native leak in a mod is the cause and the pack author needs the log.
If that didn't work
If the log has a java.lang.OutOfMemoryError line before the exit, this is the other problem: the heap really was too small. That page is the one you want.
If the exit code is 143, nothing killed the server for memory: something asked it to stop politely. A panel restart, a scheduled task or a deploy.
Not sure this is your problem? Paste your log and Roastd will tell you which of these it actually matched, and what else it found.
Check your own log