When a game server suddenly shuts down with a No space left on device error, administrators often panic and delete arbitrary directories, risking corrupted save databases. Uncontrolled disk growth is typically caused by accumulating system journals, core dumps, unrotated console logs, or unpruned backup archives.
This guide provides a structured workflow for diagnosing disk exhaustion on Linux VPS hosts, safely reclaiming storage without endangering world data, and automating log rotation.
Diagnostic: data blocks vs inode exhaustion#
Write failures can occur even when physical free space appears available. Linux filesystems allocate storage across two distinct structures: data blocks and index nodes (inodes).
First, inspect available physical disk blocks:
df -h /
If free gigabytes are reported but creating a test file with touch /tmp/test fails, inspect the inode allocation table:
df -i /
Inode exhaustion occurs when millions of tiny files accumulate (such as map generation caches, session tokens, or packet logging). When inode usage (IUse%) reaches 100%, the operating system refuses to write even a single-byte save file.
To identify the largest space consumers across the root filesystem, run du with limited depth:
du -ahx / 2>/dev/null | sort -rh | head -n 20
Locating unlinked open file descriptors#
A frequent issue on Linux game servers occurs when an administrator runs rm server_console.log, yet df continues to report 0 free bytes.
In Linux, rm only unlinks the filename from directory entries. If a running game process holds that file open, disk blocks remain allocated until the file descriptor closes or the process terminates.
Identify unlinked open files using lsof:
lsof +L1 2>/dev/null | grep -E "(deleted|log)"
The output reveals the process ID (PID) and file descriptor (FD). If an active gaming session prevents an immediate restart, truncate the file contents in-place via /proc:
truncate -s 0 /proc/$(pgrep -f "dedicated")/fd/1 2>/dev/null || true
Safe cleanup of journals and temporary caches#
Before modifying any game data, reclaim space by vacuuming transient buffers and system logs that do not affect server state:
journalctl --vacuum-size=500M --vacuum-time=7d
Next, clear SteamCMD staging caches and crash dump archives:
rm -rf /tmp/*.dmp /tmp/dumps /var/tmp/*
rm -rf ~/.steam/appcache ~/.local/share/Steam/package/tmp
Check the root filesystem for kernel core dumps generated by past engine crashes:
find / -maxdepth 3 -name "core.[0-9]*" -type f -exec rm -f {} + 2>/dev/null
Configuring log rotation and quota prevention#
To prevent recurring disk saturation from game console output, configure the system logrotate daemon. Create a dedicated configuration file:
cat << 'EOF' | sudo tee /etc/logrotate.d/gameserver
/opt/gameserver/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
copytruncate
}
EOF
The copytruncate directive is essential: it copies the active log into an archive and truncates the original file in-place without restarting the game daemon.
For complete service isolation and automated threshold alerts, administrators rely on a dedicated server management platform, where game volumes remain separate from the root partition and disk health is actively monitored.
