Когда игровой сервер внезапно завершает работу с ошибкой No space left on device, администраторы часто в панике удаляют случайные файлы, рискуя повредить базу сохранений. Неконтролируемый рост дискового пространства обычно вызван разрастанием системных журналов, дампов памяти, неуправляемых консольных логов или старых архивов бэкапов.
Данное руководство разбирает системный алгоритм выявления причин переполнения диска на Linux VPS, безопасного освобождения пространства без повреждения игровых миров и настройки автоматической ротации.
Диагностика: блоки диска или исчерпание inodes#
Ошибка записи может возникнуть даже в том случае, если свободное дисковое пространство визуально отображается в проводнике. В файловых системах Linux пространство распределяется как по блокам данных, так и по индексным дескрипторам (inodes).
Сначала проверьте доступный объем физических блоков диска:
df -h /
Если утилита показывает свободные гигабайты, но создание любого тестового файла через touch /tmp/test завершается ошибкой, проверьте таблицу inodes:
df -i /
Исчерпание inodes происходит при накоплении миллионов крошечных файлов (например, кэш генерации карты, сессионные токены или логирование каждого сетевого пакета). Если процент использования inodes (IUse%) равен 100%, сервер не сможет записать даже однобайтовый файл сохранения.
Для поиска директорий с наибольшим весом используйте утилиту du с ограничением глубины:
du -ahx / 2>/dev/null | sort -rh | head -n 20
Поиск удерживаемых дескрипторов удалённых файлов#
Распространённая проблема на игровых серверах: администратор удалил гигантский лог rm server_console.log, но утилита df продолжает показывать 0 байт свободного места.
В Linux удаление файла через rm лишь удаляет имя файла из каталога. Если запущенный процесс игрового сервера продолжает держать этот файл открытым, блоки на диске остаются занятыми до закрытия дескриптора или перезапуска процесса.
Найдите удерживаемые файлы с помощью команды lsof:
lsof +L1 2>/dev/null | grep -E "(deleted|log)"
Вы увидите идентификатор процесса (PID) и номер файлового дескриптора (FD). Если перезапустить сервер прямо сейчас нельзя из-за активной игровой сессии, освободите дисковые блоки обнулением содержимого через псевдофайловую систему /proc:
truncate -s 0 /proc/$(pgrep -f "dedicated")/fd/1 2>/dev/null || true
Безопасная очистка системных журналов и кэша#
Перед вмешательством в файлы игрового мира очистите временные буферы и системные журналы, которые не влияют на работу игрового процесса:
journalctl --vacuum-size=500M --vacuum-time=7d
Далее проверьте и удалите временные пакеты установщика SteamCMD и дампы сбоев:
rm -rf /tmp/*.dmp /tmp/dumps /var/tmp/*
rm -rf ~/.steam/appcache ~/.local/share/Steam/package/tmp
Проверьте директорию краш-дампов операционной системы. Если сервер аварийно падал несколько раз, ядро могло сохранить дампы памяти core размером в несколько гигабайт каждый:
find / -maxdepth 3 -name "core.[0-9]*" -type f -exec rm -f {} + 2>/dev/null
Настройка ротации логов и защита от переполнения#
Чтобы предотвратить повторное заполнение накопителя консольным выводом, настройте штатный демон logrotate. Создайте файл конфигурации для игрового лога:
cat << 'EOF' | sudo tee /etc/logrotate.d/gameserver
/opt/gameserver/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
copytruncate
}
EOF
Параметр copytruncate критически важен: он копирует текущий лог в архив и обрезает исходный файл без перезапуска процесса и без разрыва дескрипторов.
Для изоляции серверных служб и автоматического мониторинга дисковых квот удобно использовать возможности панели управления серверами, где разделы данных отделены от системного корня, а метрики заполнения диска отслеживаются превентивно.
