A game server process suddenly disappearing without an error message in its console is a classic system administration challenge. The server stops responding, while the last line in latest.log records an ordinary in-game event. On Linux, a process never terminates without leaving a trace: the kernel and service supervisor always record an exit status, POSIX signal, or memory exhaustion event.
This guide targets Linux game server administrators. As of October 28, 2026, standard diagnosis relies on POSIX signal mapping, kernel ring buffer analysis, and systemd supervisor status.
What process exit codes reveal#
When a process terminates under Linux, it returns an integer exit code. If termination was triggered by an operating system signal, the code equals 128 + signal number:
| Exit Code | Signal | Common Cause |
|---|---|---|
137 | SIGKILL (signal 9) | Terminated by Linux OOM Killer or Docker cgroup memory limit |
139 | SIGSEGV (signal 11) | Segmentation fault: invalid memory dereference, corrupted mod, or incompatible binary library |
143 | SIGTERM (signal 15) | Graceful shutdown requested by systemd, a scheduler, or systemctl stop |
134 | SIGABRT (signal 6) | Abort called by a failed runtime assertion in C++ or JVM code |
1 | General error | Configuration syntax error, port collision, or insufficient directory permissions |
Query the exit status of a failed systemd unit with a single command:
systemctl show game-server.service -p Result -p ExecMainStatus -p ExecMainCode
If the output displays Result=oom-kill or ExecMainStatus=137, the game server was terminated due to physical or containerized memory exhaustion.
Checking the kernel ring buffer for OOM Killer events#
When an exit status of 137 occurs, inspect the kernel ring buffer using dmesg:
sudo dmesg -T | grep -i -E 'oom[-_]killer|killed process'
If the host exhausted RAM, the kernel logs an entry detailing the process ID, binary name, and memory consumption:
Out of memory: Killed process 41829 (RustDedicated) total-vm:18492012kB, anon-rss:14201948kB
This confirms definitively that the crash was not caused by a software bug, but by physical memory exhaustion or a restrictive cgroup limit.
Auditing service output with journalctl#
If kernel logs show no memory events, inspect stdout and stderr captured by journalctl:
sudo journalctl -u game-server.service -e -n 100 --no-pager
Look for critical failure indicators right before process termination:
Address already in use— another instance or orphan process occupies the listening port.Permission denied— the service user lacks read or write access to the save directory.Failed to open descriptor— the process exceeded the maximum open file limit (nofile).
Inspecting Segmentation Fault core dumps with coredumpctl#
When a server crashes with code 139 (SIGSEGV), the operating system captures memory access violations.
List recorded crash dumps using coredumpctl:
coredumpctl list
Examine the stack trace of the latest crash:
coredumpctl info
The Stack trace reveals the exact dynamic library (.so) where execution failed, identifying whether the culprit was a community mod, a system graphics driver, or the core game engine binary.
If you manage game hosting infrastructure using Nexardo, monitor supervisor exit codes and memory allocations through a unified dashboard: automated telemetry collection helps resolve crash causes before they disrupt players again.
