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

MAATRIX GAMES

Запускаете factorio --start-server, а вместо привычного "Hosting game" в консоли — либо тишина, либо процесс падает через долю секунды с непонятной строкой. Знакомая ситуация: headless-бинарник Factorio капризен к мелочам — библиотекам, правам, занятым портам — и без системного разбора можно час потерять на угадайку. Разберём причины по порядку, от самой частой к самой редкой, с конкретными командами для каждой.

Читаем лог запуска: где искать причину

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

./bin/x64/factorio --start-server saves/base.zip \
  --server-settings data/server-settings.json \
  --console-log console.log

Если сервер поднят через systemd-юнит (как в статье про автозапуск и systemd), лог смотрите через journalctl:

sudo journalctl -u factorio -n 100 --no-pager

Типичные строки и что они значат:

• Error CommandLineArgs.cpp:... Data path does not exist — путь к data/ указан неверно или папка не распаковалась. Проверьте, что запускаете бинарник из корня распакованного архива, а не откуда-то ещё.
• Error Util.cpp:... Failed to load mod... — проблема не в самом сервере, а в моде: несовместимая версия или битый архив в mods/. Временно переименуйте папку mods в mods.bak и попробуйте запустить без модов — если стартует, ищите виновника среди модов по одному.
• Segmentation fault без внятного сообщения Factorio — почти всегда либо несовместимость версии сейва с версией сервера, либо нехватка памяти (см. ниже про OOM).
• Полная тишина, процесс просто исчезает — первый подозреваемый: убийство процесса ядром из-за нехватки RAM. Проверьте сразу после падения:

dmesg -T | grep -i "killed process"

Если видите строку про factorio рядом с Out of memory, значит, дело не в конфиге, а в ресурсах VPS — на 2 ГБ RAM (минимум для Factorio) сервер должен помещаться на старте карты, но с ростом базы, автосейвами и, тем более, тяжёлыми модами вроде Krastorio 2 или Space Exploration память может закончиться уже на этапе загрузки сейва.

Общие принципы разбора логов и краш-репортов подробнее разобраны в статье про логи и краш-репорты игровых серверов — тот же подход применим и к Factorio.

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

Headless-сборка Factorio — нативный Linux-бинарник, собранный под конкретный набор системных библиотек. На минимальных образах VPS (особенно "голый" Debian или Ubuntu Server без десктоп-пакетов) части этих библиотек может не быть, и тогда сервер падает сразу при запуске с ошибкой вида error while loading shared libraries.

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

ldd ./bin/x64/factorio | grep "not found"

Если список не пуст — доустановите нужные пакеты. Для актуальных версий headless-сборки на Debian/Ubuntu чаще всего достаточно базового набора:

sudo apt update
sudo apt install -y libc6 libstdc++6 zlib1g

На CentOS/AlmaLinux аналог:

sudo dnf install -y glibc libstdc++ zlib

Отдельно стоит проверить архитектуру: headless-сервер Factorio собирается только под x86_64. Если по ошибке арендован ARM-инстанс (бывает у дешёвых облачных тарифов) — бинарник не запустится в принципе, никакие библиотеки не помогут, единственное решение — переехать на VPS с x86_64.

Ещё одна частая причина именно "тихого" падения без внятной ошибки — не хватает свободных файловых дескрипторов или лимит ulimit слишком низкий на некоторых захостингованных контейнерных VPS. Проверить текущий лимит:

ulimit -n

Значения ниже 1024 иногда режут игровые серверы с активным сетевым обменом. Поднять лимит можно в /etc/security/limits.conf или прямо в systemd-юните строкой LimitNOFILE=65536 в секции [Service].

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

Если сервер ставили не с прямой закачки с factorio.com, а через SteamCMD (некоторые администраторы предпочитают этот способ, потому что тот же инструмент уже используется для десятка других игр — Rust, CS2, ARK), стоит проверить целостность файлов отдельно. Общая логика работы со SteamCMD для игровых серверов разобрана в статье про установку и обновление серверов через SteamCMD; для Factorio команда обновления с проверкой файлов выглядит так:

./steamcmd.sh +force_install_dir ~/factorio-server \
  +login <ваш_steam_логин> \
  +app_update 427520 validate \
  +quit

Флаг validate — ключевой: он сверяет контрольные суммы всех файлов игры с манифестом Steam и перекачивает битые или недостающие. Именно так обычно лечится ситуация, когда сервер стартовал раньше, а после обрыва интернета при обновлении или внезапной перезагрузки VPS во время распаковки перестал запускаться без внятной причины — часть файлов в data/ или bin/ могла остаться недокачанной.

Если ставили официальным способом — прямой закачкой headless-архива — переустановка делается проще, без Steam-аккаунта вообще:

cd ~/factorio-server
sudo systemctl stop factorio
mv factorio factorio.old
wget https://factorio.com/get-download/stable/headless/linux64 -O factorio-headless.tar.xz
tar -xJf factorio-headless.tar.xz
cp factorio.old/saves/*.zip factorio/saves/
cp factorio.old/data/server-settings.json factorio/data/
sudo systemctl start factorio

Так вы получаете гарантированно целый архив с нуля, а сейвы и конфиг переносите вручную — они не портятся при повреждении бинарника, если сама файловая система на VPS в порядке. После переустановки полезно на всякий случай прогнать проверку диска (fsck в safe mode при следующей перезагрузке или smartctl -a /dev/sda на выделенных серверах), если повреждения файлов повторяются регулярно — это симптом проблем с диском, а не с самой игрой.

Занят порт: конфликт по UDP 34197

Отдельная категория "не запускается" — когда сам процесс Factorio стартует и даже пишет что-то в лог, но игроки не могут подключиться, либо сервер сразу падает с ошибкой биндинга сокета вроде Failed to bind... Address already in use.

Проверить, что порт 34197 (или тот, что указан флагом --port) реально свободен и слушается именно Factorio:

ss -uln | grep 34197

Если строка есть, но занята другим процессом — узнать, кем:

sudo lsof -i :34197

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

pkill -f "factorio --start-server"

и только после этого запускайте заново. Если конфликта процессов нет, а порт всё равно "занят" — иногда виноват сам systemd, который пытается перезапустить сервис слишком быстро после падения (параметр RestartSec в юните), и новый процесс стартует раньше, чем старый успел освободить сокет; в таком случае увеличьте RestartSec до 10-15 секунд.

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

Права доступа к бинарнику и рабочей директории

Ошибка Permission denied при запуске — почти всегда одна из двух причин: либо у файла bin/x64/factorio не выставлен флаг исполняемости, либо пользователь, от которого крутится процесс (особенно если это systemd-юнит с явным User=), не имеет прав на директорию сервера.

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

ls -l bin/x64/factorio
chmod +x bin/x64/factorio

Если сервер запускается вручную от одного пользователя, а через systemd — от другого (частая ошибка при копировании конфигов с чужого гайда, где в примере стоит User=factorio, а реальный пользователь на VPS другой), процесс не сможет читать сейвы и писать автосейвы, даже если сам бинарник запустится. Проверьте владельца директории:

ls -la ~/factorio-server/factorio
sudo chown -R youruser:youruser ~/factorio-server/factorio

Отдельно стоит проверить права на конкретно папку saves/ — если автосейвы не могут записаться из-за прав, сервер иногда не падает сразу, а зависает на попытке сохранения и выглядит как "не отвечает", хотя формально процесс жив. Смотрите за такими зависаниями в логе — сообщение Saving finished должно появляться регулярно, если autosave_interval настроен в конфиге.

Битый сейв или конфиг server-settings.json

Если бинарник запускается и библиотеки на месте, а падение происходит именно на загрузке — проверьте сам сейв и JSON-конфиг отдельно.

Сейв Factorio — это zip-архив определённой структуры. Проверить, что архив не битый физически, можно простой распаковкой:

unzip -t saves/base.zip

Если unzip ругается на CRC-ошибку или "unexpected end of file" — сейв повреждён (частая причина — обрыв при копировании по сети или нехватка места на диске в момент автосейва) и не восстановится обычными средствами; остаётся откатываться на бэкап или предыдущий автосейв-слот из autosave_slots.

Конфиг server-settings.json — обычный JSON, и одна лишняя запятая или незакрытая скобка ломает парсинг целиком, при этом сообщение об ошибке у Factorio не всегда явно указывает на строку. Быстрая проверка синтаксиса без запуска игры:

python3 -m json.tool data/server-settings.json > /dev/null && echo "JSON valid"

Если команда ругается — она покажет строку и позицию ошибки, и почти всегда причина в ручном редактировании конфига текстовым редактором с автозаменой кавычек на "красивые" (типографские) — используйте nano или vim в терминале, а не копипаст из Word или заметок с телефона.

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