Game Server Suddenly Stops: Diagnose Memory Pressure and Exit 137
Published and official references checked 2026-09-07 · SameOS operator
Everyone disconnects and the container shows Exited (137). Should you add RAM? The code suggests a forced termination but does not establish memory exhaustion. Match game, container and kernel evidence at the same time before deciding whether a memory limit or a forced shutdown caused it.
1. Capture evidence before recreating the container
Recreation can remove the state you need. Record the container, finish time, OOMKilled and ExitCode first. Query selected fields because full inspection can expose credentials in environment variables.
After an automatic restart, State may no longer describe the failure you are investigating. Preserve the relevant container ID and logs; if evidence has disappeared, leave the cause unconfirmed.
docker inspect --format 'Exit={{.State.ExitCode}} OOM={{.State.OOMKilled}} Finished={{.State.FinishedAt}} Restarts={{.RestartCount}}' mc-server
docker logs --timestamps --since 30m --tail 200 mc-server2. Exit 137 and OOMKilled are different evidence
In the usual Unix convention, 137 is 128+9 and is associated with SIGKILL. A kernel OOM kill, an administrator action or an expired graceful-stop timeout can produce it. A program can also return the same number itself, so the code alone is insufficient.
OOMKilled=true is Docker evidence of an OOM termination. Match the time and victim against kernel messages. False or missing logs do not conclusively exclude memory pressure: restart history, retention and permissions affect what remains.
sudo journalctl -k --since "30 minutes ago" --no-pager
free -h
docker stats --no-stream mc-server3. Separate host memory from the container limit
A container can hit its hard limit while the host still has free RAM. Memory below is in bytes; zero means no explicit Docker limit at that setting. Parent cgroups or service management may impose other limits.
One docker stats snapshot describes now, not a peak during world generation, many simultaneous joins or overlapping maintenance. Correlate periodic measurements with activity times to identify recurrence conditions.
docker inspect --format 'Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}}' mc-server4. Leave room beyond the Minecraft Java heap
Java -Xmx limits the heap, not total process memory. Metaspace, thread stacks and direct buffers also need room. Setting both a container limit and Xmx to 6 GiB leaves no separately budgeted space for those allocations. This is an illustrative configuration, not a sizing recommendation.
OutOfMemoryError: Java heap space and the kernel killing Java can require different responses. Inspect heap demand and mod allocations for the former; inspect total process, container and host limits for the latter. Raising Xmx blindly can worsen the second case.
5. If it happens during maintenance, inspect stop timeouts
A stop timeout can expire while the game is saving, leading to forced termination. Compare the update or shutdown time with logs and look for completed saves. Treat this separately from increasing memory use during ordinary play.
Check how your game and image handle saves and shutdown signals, then measure a normal save and allow headroom. A longer timeout cannot fix a hung process or incorrect signal forwarding. After repeated forced stops, validate the world using a separate restore copy.
6. Change one factor and retest under comparable play
If evidence points to the container limit, check host capacity and other services before adjusting it. If growth began after a mod change, preserve the live world and test the mod/loader combination on a copy. Xmx is irrelevant to a non-Java game such as Palworld.
Scheduled restarts can hide accumulation without explaining it. Swap is slower than RAM and may increase game latency. Address memory budgets and overlapping work instead of disabling OOM protection.
Record the single change, game/mod builds, player count, play duration, peak memory, save success and forced exits. Verification should include the activity that previously failed and a graceful save/restart, not merely a successful boot.
Verification scope and official references
This Linux operations guide was checked against the linked documentation and command options. Paths, service names, addresses and diagnostic scenarios are illustrative, not incident reports or performance measurements from SameOS game servers. We did not induce production failures or modify production saves. Confirm paths and behavior for your game build and deployment before applying changes.