Dedicated game servers face recurring operational challenges: memory leaks, unhandled plugin exceptions, or kernel resource pressure can crash the primary game process. If a server is launched manually in a terminal session or managed via a naive while true loop, it either remains offline until morning or enters an uncontrolled restart loop, saturating CPU capacity and filling storage with core dumps.
This guide details how to construct a resilient auto-restart architecture using systemd: incorporating restart rate limits, adequate shutdown grace periods for save persistence, and forensic crash analysis.
Distinguishing Restart=always from Restart=on-failure#
Many server operators configure units with Restart=always. Under this directive, systemd restarts the daemon even when an administrator deliberately stops the process for planned maintenance.
The Restart=on-failure directive operates selectively:
- Clean process exits with code
0(clean shutdown or save-and-exit commands) do not trigger a restart. - Abrupt terminations by kernel signals (
SIGSEGV,SIGKILL), non-zero error codes, or watchdog timeouts invoke automatic recovery.
Always define a cooldown interval with RestartSec:
[Service]
Restart=on-failure
RestartSec=10
A 10–15 second pause allows the operating system to release bound TCP/UDP sockets and reclaim memory pages before the binary restarts.
Mitigating infinite crash loops with StartLimitBurst#
If a configuration file becomes corrupted or an updated engine binary is missing a shared library, the process will crash immediately upon initialization. Without safeguards, the host enters a rapid restart storm, spinning CPU cores and generating megabytes of redundant log files.
Shield your system using unit-level burst protection directives:
[Unit]
Description=Resilient Dedicated Game Server
After=network.target
StartLimitIntervalSec=300s
StartLimitBurst=5
This configuration establishes that if the server crashes more than 5 times within 5 minutes (300 seconds), systemd places the unit into a failed state and stops restarting, protecting host resources.
Graceful shutdown parameters and world save timeouts#
Multiplayer game engines (such as Minecraft, CS2, Palworld, and Rust) require sufficient time to flush chunk buffers, player inventories, and database transactions when receiving a termination signal.
By default, systemd allows only 90 seconds before sending an uncatchable SIGKILL, which risks corrupted save headers.
Configure explicit termination signals and extended stop timeouts:
[Service]
KillSignal=SIGTERM
TimeoutStopSec=60
FinalKillSignal=SIGKILL
A production-ready resilient service unit template:
cat << 'EOF' | sudo tee /etc/systemd/system/gameserver-resilient.service
[Unit]
Description=Resilient Dedicated Game Server
After=network.target
StartLimitIntervalSec=300s
StartLimitBurst=5
[Service]
Type=simple
User=gameserver
Group=gameserver
WorkingDirectory=/opt/gameserver
ExecStart=/opt/gameserver/server_binary -dedicated +port 27015
Restart=on-failure
RestartSec=10
KillSignal=SIGTERM
TimeoutStopSec=60
[Install]
WantedBy=multi-user.target
EOF
Apply the service unit:
sudo systemctl daemon-reload
sudo systemctl enable gameserver-resilient
Crash diagnostics and restart event auditing#
To investigate why a game process restarted overnight, query system journals filtered by time and fatal termination signatures:
journalctl -u gameserver-resilient --since "12 hours ago" --no-pager | grep -E "(Failed|exit|Killed|signal)"
Use systemctl show to inspect the exact termination status and exit code of the preceding run:
systemctl show gameserver-resilient -p Result -p ExecMainStatus -p ExecMainCode
For continuous service health monitoring and real-time incident alerting via webhook channels, administrators deploy a modern server management platform, where automatic daemon self-healing and telemetry metrics operate out of the box.
