Collect the termination time and operating-system evidence before restarting a Palworld server repeatedly. Exit code 137 or a lone Killed message establishes abrupt termination, not its cause. You need to connect the game process to an out-of-memory event and identify whether the exhausted boundary belongs to the host, service, container or VM.
This guide covers Linux dedicated servers and optional Docker/cgroup v2 deployments. Examples use palworld.service from our setup guide; substitute your own service or container. Sources were checked on October 18, 2026, against Pocketpair's documentation displaying 1.0.4. No universal RAM budget can replace measurements of your world and workload.
Preserve the failure window#
Record when players disconnected, the last successful save and any automatic restart. Read the service and kernel logs around that time before they rotate:
date --iso-8601=seconds
sudo systemctl show palworld -p Result -p ExecMainCode -p ExecMainStatus -p NRestarts -p MainPID
sudo journalctl -u palworld --since '1 hour ago' --no-pager
sudo journalctl -k --since '1 hour ago' --no-pager
journalctl -k selects the current boot. If the host rebooted after the incident, use sudo journalctl --list-boots to identify the retained boot, then inspect it with sudo journalctl -k -b -1 when it is the immediately preceding one. Compare that boot’s timestamps with the game failure; an absent retained journal does not disprove OOM.
Adjust the time window to the incident. Look for an OOM event naming the killed process and its cgroup, then correlate it with the game's termination. Compare timestamps and boot identity; yesterday's kernel message does not explain today's unrelated crash. If kernel messages are restricted or stored elsewhere, obtain the host administrator's record rather than treating an empty search as proof against OOM.
A failed allocation inside the game can also produce an application-level out-of-memory error without a kernel kill. Preserve that crash log separately. Conversely, a SIGKILL may come from an administrator, supervisor stop timeout or another policy. Do not convert every abrupt exit into a claimed memory leak.
Compare available host memory with the service ceiling#
free -h
sudo systemctl show palworld -p MemoryCurrent -p MemoryPeak -p MemoryHigh -p MemoryMax -p ControlGroup
free describes the host where it runs. It does not tell you how much a restricted service may allocate, and the host may itself be a VM with a smaller assigned budget than the physical machine. Inspect parent slices or the container boundary too: a permissive unit cannot override a tighter ancestor limit.
On a unified cgroup v2 system, while the relevant service cgroup still exists:
(
set -e
palworld_cgroup=$(systemctl show palworld -p ControlGroup --value)
test -n "$palworld_cgroup"
test "$palworld_cgroup" != /
sudo test -f "/sys/fs/cgroup${palworld_cgroup}/memory.events"
sudo cat "/sys/fs/cgroup${palworld_cgroup}/memory.current"
sudo cat "/sys/fs/cgroup${palworld_cgroup}/memory.max"
sudo cat "/sys/fs/cgroup${palworld_cgroup}/memory.events"
)
The kernel's cgroup documentation defines these files. A finite memory.max is a boundary, not installed host RAM; a rising oom_kill count indicates an OOM kill involving this cgroup's processes. Retain before/after values and correlate the event window: cumulative counters alone do not identify one incident. Recreated cgroups can reset them. If the unit has exited and its cgroup disappeared, use preserved logs and the supervisor's records.
systemd's resource-control reference also distinguishes throttling at MemoryHigh from the hard MemoryMax boundary. Pressure and slower saves can occur before a kill. Increasing the latter blindly may merely move pressure to other services or the whole host.
In Docker, distinguish the game from its wrapper#
For a container actually named palworld:
docker inspect --format '{{json .State}}' palworld
docker inspect --format 'Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}}' palworld
docker stats --no-stream palworld
Use Docker administration rights through your established access method. Inspecting a newly recreated container does not preserve the state of the old one. Save the original container identity and failure time. .State.OOMKilled helps when that container terminated from OOM, but it is not a complete detector for a game child killed while a wrapper remains alive. Check host kernel evidence and the appropriate cgroup counters too.
Docker's memory-limit documentation explains why spare memory elsewhere on the machine does not erase a configured container ceiling. Keep host, cgroup and process measurements labeled separately; process RSS and container totals are different quantities.
Measure comparable runs instead of guessing a leak#
Record the exact server build, native Linux or Wine runtime, mods, world age, players, bases, Pals and save activity. Sample memory at consistent intervals after startup, with no players, during the same active workload and through a save. Preserve the timestamps rather than only a dashboard maximum.
A July 2026 administrator report describes increasing memory and kernel kills in a Wine/container setup even after enlarging its limit. That is one reported environment, not evidence that every native server shares its cause or that its figures define your required allocation.
Change one factor per comparison. Reproduce on an independent copy when changing mods, runtime or world settings; do not remove content and save over the only world. A rising curve during new workload is a symptom worth tracking. Calling it a leak needs stronger evidence than a large number or the fact that a restart lowered usage.
Choose mitigation and verify recovery#
Pocketpair's requirements list 16 GB and recommend more than 32 GB, while warning about OOM risk at 8 GB. Those figures are guidance, not a capacity guarantee for a developed world. Leave headroom for the OS, other workloads and save-time peaks; choose limits from measured behavior.
Possible responses include reducing concurrent workload, allocating genuinely available memory, separating competing services or testing a relevant fixed server build. Review current arguments too: Pocketpair's 1.0 guidance no longer presents old performance flags as an automatic improvement. A scheduled restart may provide temporary operational relief, but does not establish a fixed cause; save and shut down gracefully rather than regularly forcing SIGKILL.
After any forced termination, preserve the current complete save tree before further experiments. Start the intended world, inspect loading and save errors, join, verify important progress and perform one graceful save/restart. Acceptance requires a comparable workload without a new correlated OOM event, plus intact persistence. Record the observation period honestly; a short idle run cannot demonstrate stability through the previous peak.
