Don't Starve Together: краш сервера при загрузке мира

MAATRIX GAMES

Заходишь на сервер Don't Starve Together, а он вместо загрузки мира падает — процесс вылетает через пару секунд после старта, игроки в Steam видят "connection failed", а в консоли тишина или обрывок стектрейса. Знакомая картина, и почти всегда причина одна из трёх: битый файл сохранения, серверу банально не хватило памяти на загрузку мира, или моды разъехались после обновления. Разберём по порядку, как найти виновника и поднять сервер обратно, не потеряв прогресс игроков.

Сначала — смотрим лог, а не гадаем

Первое, что нужно сделать при краше — открыть server_log.txt. Он лежит в папке шарда, а не рядом с исполняемым файлом:

~/.klei/DoNotStarveTogether/<ClusterName>/Master/server_log.txt
~/.klei/DoNotStarveTogether/<ClusterName>/Caves/server_log.txt

Если у кластера включены пещеры, крашится может либо Master, либо Caves — проверяй лог того шарда, который реально упал (в консоли/systemd-статусе видно, какой процесс завершился с ошибкой).

Полезно на время диагностики запустить сервер вручную, в foreground, без tmux/systemd, чтобы видеть вывод live:

cd ~/dst_server/bin64
./dontstarve_dedicated_server_nullrenderer_x64 -console -cluster Cluster_1 -shard Master

В логе ищи характерные строки:

• LOAD ERROR / [string "..."]:N: attempt to index a nil value — чаще всего мод-конфликт, ошибка в Lua-скрипте мода при загрузке сохранённых сущностей.
• Failed to load save data или обрыв лога сразу после Loading world save — подозрение на битый файл сейва.
• Лог просто обрывается без явной ошибки, а dmesg показывает Out of memory: Killed process — это нехватка RAM, процесс убил OOM killer ядра.

Подробнее про то, как читать краш-репорты и выцеплять из них конкретную причину, — в статье про логи и крэш-репорты, там разобран общий подход для любых игровых серверов, не только DST.

Причина 1: повреждённый файл сохранения

DST хранит мир не одним файлом, а серией инкрементальных сохранений в папке сессии:

~/.klei/DoNotStarveTogether/<ClusterName>/Master/save/session/<хэш-сессии>/

Внутри — пронумерованные архивы вида 0000000001.zip, 0000000002.zip и так далее, каждый следующий содержит дельту изменений мира. Если сервер упал посреди записи (например, вырубили питание хоста или процесс убили kill -9 во время автосейва), последний по номеру файл может оказаться битым или недописанным — именно его сервер и пытается прочитать при старте, падая на этом шаге.

Проверить гипотезу просто: временно переименуй последний файл сессии (например, добавь .bak к имени) и попробуй запустить сервер снова. Если он поднимется — значит, дело было в этом файле, и сервер откатится к предыдущему сохранённому состоянию (обычно это потеря нескольких минут игры, не больше — DST сохраняется часто).

cd ~/.klei/DoNotStarveTogether/Cluster_1/Master/save/session/<хэш>/
ls -la
mv 0000000042.zip 0000000042.zip.bak

Если проблема была не в последнем файле, а глубже — это уже сигнал, что сессия повреждена основательно и разумнее восстанавливаться из бэкапа (см. ниже), а не пытаться руками перебирать десятки архивов.

Отдельно: если у тебя несколько серверов или ты переносишь мир между хостингами, чтобы не наступать на эти же грабли при копировании — почитай про экспорт и импорт игрового мира между серверами, там про то, как переносить сохранения корректно, не обрывая файлы на середине.

Причина 2: серверу не хватает памяти

DST — не самая тяжёлая игра по RAM, но при загрузке мира (особенно давнего, с большим количеством построек и предметов на земле) потребление памяти скачком растёт, и если лимита впритык — процесс валится с OOM прямо на этапе десериализации сохранения.

Проверить, было ли это OOM-убийство, а не краш самой игры:

dmesg -T | grep -i "killed process"
journalctl -k --since "1 hour ago" | grep -i oom

Если видишь в выводе dontstarve_dedicated_server рядом с "Out of memory" — вопрос решён, дело в памяти. Дальше смотри текущее потребление и свободный объём:

free -h
htop

Ориентировочно: один шард DST без модов на вменяемом по возрасту мире держится в пределах 1-2 ГБ, но это именно ориентир — реальная цифра зависит от количества построек, предметов, длительности жизни мира и особенно от модов (некоторые крупные QoL- и контент-моды заметно поднимают потребление). Если кластер работает с пещерами — это два процесса (Master и Caves) одновременно, и памяти нужно закладывать под оба шарда сразу, а не под один.

Что делать:

• Проверить, не пытаешься ли ты уместить Master + Caves + другие сервисы на хосте в 1 ГБ RAM — это частая причина именно "краш строго на загрузке", а не в процессе игры.
• Временно отключить пещеры (caves_enabled = false в cluster.ini), поднять только Master — если так грузится нормально, дело точно в памяти.
• Добавить своп как временную подстраховку (не решение навсегда, но снимает жёсткий OOM-килл на время диагностики):

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

• Если сервер стабильно упирается в лимит — банально апгрейднуть тариф. В каталоге MAATRIX GAMES под Don't Starve Together базовый тариф стартует от 1 ГБ, но для кластера с пещерами и модами разумнее сразу брать с запасом — переезд на больший тариф без модов и потери мира занимает пару минут.

Общую методику расчёта, сколько памяти закладывать под игровой сервер вообще (не только DST), можно посмотреть в статье про выбор объёма RAM под игровой сервер.

Причина 3: конфликт модов после обновления

Самый частый сценарий: всё работало, потом либо вышло обновление самой игры, либо один из модов в Steam Workshop обновился автоматически (Steam обновляет подписанные моды сам, без спроса) — и на следующей загрузке мира сервер начинает падать с ошибкой в Lua-скрипте.

Список активных модов сервера — в файле:

~/dst_server/mods/dedicated_server_mods_setup.lua

А персональные настройки каждого мода на конкретный шард — в:

~/.klei/DoNotStarveTogether/Cluster_1/Master/modoverrides.lua
~/.klei/DoNotStarveTogether/Cluster_1/Caves/modoverrides.lua

Если краш появился именно после апдейта — первым делом смотри server_log.txt: обычно там прямо указан путь к скрипту мода, на котором всё упало (что-то вроде .../mods/workshop-XXXXXXXXXX/scripts/...). Это сразу даёт подозреваемого.

Если лог неинформативен, ищи бинарным поиском — отключи половину модов в modoverrides.lua (поставь enabled = false у соответствующих записей), попробуй загрузиться. Упало снова — проблема в оставшейся половине, не упало — в отключённой. Повторяй, сужая круг, пока не останется один мод.

-- modoverrides.lua, пример записи по конкретному моду
["workshop-1234567890"] = {
    enabled = false,  -- временно выключаем для диагностики
    configuration_options = {},
},

Когда виновник найден — либо жди фикса от автора мода, либо откатывайся на рабочую версию через Steam Workshop Downloader (скачать конкретную ревизию мода вручную и подложить в папку mods/ вместо авто-обновляемой), либо просто исключи мод из кластера насовсем, если он необязателен.

Отдельная история — конфликт между модами, а не с ядром игры: два мода лезут в одни и те же прототипы сущностей и на загрузке спотыкаются друг о друга. Здесь помогает только последовательное отключение, других быстрых способов диагностики, увы, нет.

Восстановление из бэкапа

Если файл сейва битый основательно, а не только в последнем архиве, или откат на предыдущий .zip не помогает — восстанавливаемся из бэкапа. DST сам бэкапы не делает, это забота администратора, так что если их нет — на будущее стоит завести.

Простой cron-бэкап всей папки кластера раз в день:

0 4 * * * tar -czf /backups/dst-$(date +\%F).tar.gz -C /home/user/.klei/DoNotStarveTogether Cluster_1

Восстановление — остановить сервер, аккуратно сохранить текущее (битое) состояние в сторону на случай, если что-то ценное всё же можно вытащить, и развернуть бэкап на его место:

systemctl stop dst-master dst-caves   # или как у тебя называются юниты/сессии
mv ~/.klei/DoNotStarveTogether/Cluster_1 ~/.klei/DoNotStarveTogether/Cluster_1.broken
tar -xzf /backups/dst-2026-08-30.tar.gz -C ~/.klei/DoNotStarveTogether/
systemctl start dst-master dst-caves

Игроки потеряют прогресс с момента последнего бэкапа до краша — это неприятно, но предсказуемо, в отличие от попыток вручную чинить битый архив сохранения без вменяемого понимания его внутреннего формата.

Если ничего не помогло — крайние меры

Когда ни откат последнего файла сессии, ни бэкап недоступны (бэкапов не было, а других копий сейва нет), а мир нужен позарез — вариантов немного, и все с потерями:

• Полная регенерация мира. Удалить папку save шарда целиком и запустить сервер заново — он сгенерирует новый мир с теми же настройками кластера. Это чистый лист: все постройки, весь прогресс игроков теряется безвозвратно. Крайняя мера, когда мир уже не спасти.
• Пересборка кластера с нуля через настройки cluster.ini и worldgenoverride.lua, если проблема была не в конкретном сейве, а в самих настройках генерации мира (несовместимые параметры после смены версии игры).
• Обращение в поддержку хостинга, если краш происходит на уровне ниже самой игры — например, файловая система хоста повреждена, диск деградирует, и файлы сейва бьются сами по себе при каждой записи. Это редкость, но при повторяющихся битых сохранениях без видимой причины стоит проверить SMART диска и логи хоста.

Частые вопросы