Don't Starve Together: сервер не запускается — диагностика

MAATRIX GAMES

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

Сначала смотрим, что говорит консоль (или лог)

Прежде чем что-то менять — прочитайте, что написал сам сервер. Если запускали вручную с флагом -console, ошибка почти всегда видна прямо в терминале в момент падения, просто теряется в потоке вывода. Прокрутите вверх или перезапустите с выводом в файл:

./dontstarve_dedicated_server_nullrenderer_x64 -console -cluster MyDediServer -shard Master 2>&1 | tee ~/dst_start.log

Если сервер оформлен как systemd-юнит — смотрим через journalctl, там же виден код завершения процесса:

journalctl -u dst-master -n 100 --no-pager

status=1/FAILURE обычно значит, что процесс упал сам из-за конфига или окружения. signal=KILL — почти всегда OOM killer, и тогда дело не в настройках, а в нехватке RAM (для DST это редкость — игра лёгкая, но с модами и обоими шардами на 1 ГБ памяти уже можно упереться). Отдельно сам сервер по ходу игры пишет server_log.txt внутри папки конкретного шарда (~/.klei/DoNotStarveTogether/MyDediServer/Master/server_log.txt) — если файл вообще не появился, значит, процесс упал ещё до инициализации, и причина в бинарнике или окружении, а не в игровых настройках. Общий разбор того, как читать логи и краш-репорты игровых серверов — в статье логи и краш-репорты: как читать и искать причину.

Не хватает 32-битных библиотек

Самая частая причина отказа на свежем VPS — сервер DST собран как 32-битное приложение (даже несмотря на _x64 в имени бинарника — это по-прежнему сборка, зависящая от i386-библиотек), а на минимальном образе Ubuntu/Debian их просто нет. Симптом — сообщение вроде:

bash: ./dontstarve_dedicated_server_nullrenderer_x64: cannot execute binary file: Exec format error

или тихий Segmentation fault (core dumped) без единой другой строки. Проверяем, что архитектура i386 вообще подключена и стоят нужные пакеты:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y lib32gcc-s1 lib32stdc++6 libcurl4-gnutls-dev:i386

На старых дистрибутивах пакет может называться lib32gcc1 вместо lib32gcc-s1 — если apt ругается на отсутствие пакета, проверьте актуальное имя через apt search lib32gcc. После установки библиотек перезапустите сервер тем же способом — если дело было в них, падение исчезает сразу, без переустановки самой игры.

Битая установка: чиним через SteamCMD validate

Если библиотеки на месте, а сервер стартует и через пару секунд вылетает с сообщением про отсутствующий ассет или просто без текста — вероятно, установка через SteamCMD прервалась на середине (обрыв сети, нехватка места на диске во время распаковки). Лечится принудительной проверкой целостности, app id сервера DST — 343050:

steamcmd +force_install_dir ~/dstserver +login anonymous +app_update 343050 validate +quit

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

df -h ~/dstserver

5-10 ГБ свободного пространства — комфортный минимум с учётом модов и логов. Если validate не помогает и ошибка повторяется — надёжнее снести папку установки и скачать заново:

rm -rf ~/dstserver
mkdir -p ~/dstserver
steamcmd +force_install_dir ~/dstserver +login anonymous +app_update 343050 validate +quit

Подробнее про механику SteamCMD и типичные грабли при установке/обновлении дедиков в целом — в статье про установку и обновление серверов через SteamCMD.

Порт уже занят — Address already in use

Если в выводе есть что-то похожее на bind: Address already in use, или процесс вроде бы запустился, но сразу же падает и не появляется ни в браузере серверов, ни по прямому подключению — скорее всего, порт уже держит другой процесс. DST по умолчанию использует:

Такое часто бывает после аварийного рестарта: старый процесс завис в памяти и держит порт, пока новый пытается забиндиться на тот же. Проверяем, кто слушает:

sudo ss -ulnp | grep -E '10999|10998|27018|27019|8766|8767'

Если завис старый процесс — останавливаем штатно через systemctl stop dst-master dst-caves, либо, если сервис завис намертво, добиваем по PID из вывода ss. Второй вариант конфликта — два кластера DST на одной машине с одинаковыми портами по умолчанию: тогда меняем server_port во втором server.ini на свободный и открываем его отдельно в фаерволе. Общая механика проброса портов и фаервола — в статье настройка портов и файрвола для игрового сервера, а если порт открыт, но сервер всё равно не виден снаружи — гляньте порт не проброшен: как проверить и исправить.

Не найден или невалиден cluster_token.txt

Отдельная категория падений, специфичная именно для DST: сервер стартует, печатает пару строк про инициализацию и тут же завершается с сообщением о проблеме с токеном авторизации Klei. Без валидного токена процесс не запустится в режиме online — это ожидаемое поведение, а не баг.

Проверьте, что файл cluster_token.txt реально лежит в корне папки кластера (не внутри Master/ или Caves/, а на уровень выше):

ls -la ~/.klei/DoNotStarveTogether/MyDediServer/cluster_token.txt

Если файла нет — получите токен на странице аккаунта Klei, выбрав Don't Starve Together и создав новый серверный токен, затем сохраните содержимое строки целиком (она длинная, обычно начинается с eyJ...) в этот файл без лишних переносов строк в конце. Токен общий на весь кластер — Master и Caves используют один и тот же файл, отдельный токен на каждый шард не нужен. Если токен просрочен или был отозван в аккаунте Klei — симптом тот же самый, помогает только генерация нового. Подробный разбор первого запуска и получения токена — в статье как поднять сервер Don't Starve Together.

Ошибки в cluster.ini/server.ini и права на файлы

Если токен на месте, порты свободны, а сервер всё равно не встаёт (или встаёт, но игнорирует часть настроек) — вероятная причина в самом cluster.ini или server.ini. INI-парсер DST не всегда явно указывает на битую строку — вместо явной ошибки конфиг может просто откатиться к значениям по умолчанию. Частые ошибки:

• Секции без квадратных скобок или с опечаткой в названии ([NETWORK], а не [Network] — регистр обычно не критичен, но лишний пробел внутри скобок ломает парсинг).
• cluster_key в [SHARD] не совпадает между Master/server.ini и Caves/server.ini — тогда Master стартует один, а Caves не может к нему подключиться и в логе видно постоянные попытки переподключения.
• Имя папки кластера не совпадает по регистру с флагом -cluster в команде запуска — на Linux, в отличие от Windows, файловая система регистрозависима, и -cluster MyDediServer не найдёт папку mydediserver.

Также стоит проверить права на саму папку кластера и на исполняемый файл, особенно если установка делалась под root (sudo steamcmd ...), а запуск сервиса настроен от отдельного пользователя:

ls -la ~/.klei/DoNotStarveTogether/MyDediServer
sudo chown -R dstserver:dstserver /home/dstserver/.klei
chmod +x ~/dstserver/bin64/dontstarve_dedicated_server_nullrenderer_x64

И последнее: бинарник нужно запускать именно из папки bin64/ — он ищет данные игры по относительным путям, и запуск из другого рабочего каталога (например, через systemd без правильного WorkingDirectory) даёт ошибки о недостающих файлах, которые легко принять за битую установку. Про автозапуск сервиса и правильный юнит systemd — в статье автозапуск игрового сервера при перезагрузке хоста.

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