Core Keeper: сервер не запускается — диагностика

MAATRIX GAMES

Запустили CoreKeeperServer.x86_64, а вместо приветственного лога — тишина, мгновенный выход в консоль или процесс, который через пару секунд просто исчезает из ps aux. Знакомая ситуация почти для каждого, кто хоть раз поднимал dedicated-сервер Core Keeper вручную через SteamCMD. Ниже — не общие советы «перезагрузите», а разбор конкретных причин по симптомам: что смотреть в логе в первую очередь и как быстро понять, где именно сломалось.

Сначала — лог, а не догадки

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

Если сервер настроен через systemd (как в инструкции по установке Core Keeper), лог смотрите через journalctl:

journalctl -u corekeeper -n 100 --no-pager

Полезно сразу отфильтровать по уровню ошибок и посмотреть, что происходило непосредственно перед падением:

journalctl -u corekeeper -p err -n 50
systemctl status corekeeper

systemctl status покажет код выхода процесса — это первая зацепка. Код 217/USER почти всегда означает, что пользователь, указанный в юните (User=coreserver), не существует или у него нет прав на рабочую директорию. Код 1 или Segmentation fault — уже про сам бинарник или систему, тут переходим к разделу про библиотеки. Если хотите разобраться в логах глубже и системно, а не только применительно к Core Keeper — держите под рукой общий гайд по логам и краш-репортам.

Отдельно проверьте место на диске — банальная, но частая причина тихого падения:

df -h

Если раздел с установкой сервера заполнен под ноль, SteamCMD и сама игра могут вести себя непредсказуемо: от отказа писать сохранение до падения при старте без внятной ошибки в логе.

Не хватает системных библиотек

Core Keeper Dedicated Server — 64-битный Linux-бинарник, но он всё ещё тянет за собой часть 32-битных (i386) зависимостей через Steam-рантайм, как и многие серверы на Unity/Steamworks. Если на VPS свежий минимальный образ Ubuntu/Debian без мультиархитектуры, сервер может падать сразу после старта без единого сообщения об ошибке — просто выход с кодом 127 или 1.

Проверить, каких библиотек не хватает бинарнику, можно через ldd:

cd ~/coreserver
ldd CoreKeeperServer.x86_64 | grep "not found"

Если список не пустой — это и есть причина. Обычно недостающие библиотеки закрываются установкой мультиархитектуры и базовых зависимостей SteamCMD:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y libc6-i386 libstdc++6 lib32gcc-s1 lib32stdc++6

После установки повторите ldd — список not found должен опустеть. Если сервер поднимали давно и на другом дистрибутиве (например, мигрировали образ с Debian на Ubuntu или наоборот), стоит переустановить пакет steamcmd заново, а не только докидывать библиотеки — рантайм Steam иногда рассчитывает на конкретный набор системных путей.

Второй источник похожей проблемы — запуск от имени пользователя без переменных окружения HOME и LD_LIBRARY_PATH, характерных для интерактивной сессии. Если вы запускаете сервер через systemd или cron, а не руками из-под своего логина, добавьте в юнит явный Environment=HOME=/home/coreserver — иногда рантайм ищет кэш и конфиги Steam именно там.

Повреждённая установка через SteamCMD

Если библиотеки в порядке, а сервер всё равно не встаёт (падает сразу, зависает на загрузке мира дольше нескольких минут или пишет что-то про отсутствующие файлы данных) — вероятнее всего, установка через SteamCMD прервалась на середине. Это случается при обрыве сети, нехватке места на диске в момент скачивания или принудительном завершении процесса steamcmd.

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

sudo systemctl stop corekeeper
steamcmd +force_install_dir ~/coreserver +login anonymous +app_update 1963720 validate +quit

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

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

sudo chown -R coreserver:coreserver /home/coreserver/coreserver

Если SteamCMD сама падает при попытке обновления (не сервер, а именно steamcmd), почти всегда помогает полная переустановка самого SteamCMD — старые версии клиента Steam иногда ломаются после обновлений протокола CDN. Подробный процесс установки и типичные грабли SteamCMD как инструмента разобраны в отдельной статье про SteamCMD — она не про Core Keeper конкретно, но про сам инструмент, которым вы пользуетесь.

Конфликт порта

Один из самых частых симптомов — сервер вроде бы стартует (процесс виден в ps aux), но игроки не могут подключиться, а через несколько секунд процесс тихо завершается. Причина — порт уже занят другим процессом, и Core Keeper не может забиндиться на сокет.

Проверка, что реально слушает порт по умолчанию (27015):

sudo ss -tulnp | grep 27015

Если строка есть и владелец процесса — не ваш сервер, значит порт занят чем-то другим: старым «зависшим» инстансом Core Keeper после неудачного рестарта, другим игровым сервером на той же VPS или даже другим экземпляром steamcmd. Убить зависший процесс и перезапустить сервис:

sudo pkill -f CoreKeeperServer
sudo systemctl restart corekeeper

Отдельная ловушка — несколько systemd-юнитов или крон-задач, которые пытаются поднять один и тот же сервер параллельно (например, если вы тестировали ручной запуск и забыли, что systemd-юнит уже включён и тоже пытается стартовать). Проверьте список активных юнитов:

systemctl list-units --type=service | grep -i core

Если сервер вообще не биндится ни на какой порт и в логе тишина по сети — это не про файрвол, файрвол блокирует входящие соединения снаружи, но не мешает процессу запуститься локально. Разница важная: если процесс не стартует вообще — смотрите порт и права; если процесс живёт, но игроки не подключаются по IP — тогда уже проверяйте UFW и облачный файрвол хостинга, это разобрано в статье «порт не проброшен» и в общем гайде по настройке портов и файрвола.

Нехватка памяти (OOM) при старте

Core Keeper не самая прожорливая игра для dedicated-сервера, но при лимите RAM в 2 ГБ и ниже сервер может падать именно на этапе загрузки или генерации мира — момент, когда потребление памяти кратковременно выше, чем в спокойном состоянии на устоявшемся мире.

Проверить, не сработал ли OOM-killer:

dmesg -T | grep -i "killed process"
sudo journalctl -k | grep -i "out of memory"

Если в выводе есть строка про CoreKeeperServer — вот и причина. Быстрая проверка текущей загрузки памяти:

free -h

Решение временное — подключить своп, если его нет (не панацея, но снижает риск мгновенного убийства процесса под пиковой нагрузкой):

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

Решение постоянное — тариф с запасом по RAM. Ориентируйтесь на минимум 3 ГБ под спокойную игру вдвоём-вчетвером и закладывайте больше, если планируете 6-8 игроков и активное исследование карты — сервер держит в памяти посещённые чанки, и с ростом мира требования тоже растут.

Конфликты конфигурации и битое сохранение

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

Что стоит проверить:

• Права на папку сохранений. Если файл мира создавался под одним пользователем, а сервер запускается под другим (например, вы тестировали вручную от root, а systemd-юнит работает от coreserver), процесс не сможет прочитать или записать сохранение.
• Обрыв записи при предыдущем некорректном завершении. Если сервер убили жёстко (kill -9, обрыв VPS, OOM) в момент сохранения мира, файл может оказаться битым. Восстановление — из последнего рабочего бэкапа, если вы его делали.
• Несовпадение версий после обновления. После app_update версия сервера иногда обгоняет формат старого сохранения. Обычно Core Keeper мигрирует сохранения автоматически, но если после обновления сервер стабильно падает именно на загрузке старого мира — попробуйте временно откатить обновление (переустановкой конкретного build через +app_update 1963720 -beta none не поможет откатить версию, поэтому лучше держать резервную копию файлов сервера перед каждым app_update, а не полагаться на откат постфактум).

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

Чек-лист быстрой диагностики

Если хочется алгоритма, а не читать всё по порядку — вот сокращённая последовательность действий при падении сервера:

1. systemctl status corekeeper — смотрим код выхода.
2. journalctl -u corekeeper -n 100 — читаем последние строки перед падением.
3. ldd CoreKeeperServer.x86_64 | grep "not found" — проверяем библиотеки.
4. df -h — проверяем место на диске.
5. ss -tulnp | grep 27015 — проверяем, не занят ли порт.
6. dmesg -T | grep -i killed — проверяем OOM.
7. Если ничего не помогло — переустановка через steamcmd +app_update 1963720 validate +quit с сохранением файлов мира отдельно.

Пройдя по этому списку сверху вниз, в 9 случаях из 10 причина находится в первых трёх-четырёх пунктах.

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