После массового отключения игроков сначала выясните, завершился ли процесс Satisfactory. Если он работает, а подключение не проходит, начните с проверки подключения. Если процесс исчезает или перезапускается, нужна последовательность событий: что произошло перед остановкой и кто её вызвал. Переустановка стирает часть следов, но не устраняет лимит памяти или заполненный диск.
Разбираем существующий немодифицированный PC-сервер на Linux с systemd. В примерах: satisfactory.service, пользователь satisfactory, установка /home/satisfactory/server, HOME /home/satisfactory. Подставьте значения своей службы. У контейнера дополнительно проверяются лимиты и подключённые каталоги; для Windows потребуются журналы событий и инструменты его служб.
Зафиксируйте сбой до следующего перезапуска#
Запишите время и часовой пояс, имя сессии, последний удачный сейв и действие перед падением: загрузка мира, вход игрока, сохранение. Отметьте обновления игры, модов, ресурсов машины и хранилища. Сбой одного конкретного сохранения и падение любой новой сессии — разные случаи.
Через SSH выполните проверки, которые ничего не меняют:
sudo systemctl show satisfactory.service \
-p ActiveState -p SubState -p Result -p MainPID \
-p ExecMainCode -p ExecMainStatus -p NRestarts
sudo systemctl cat satisfactory.service
sudo journalctl -u satisfactory.service --since '-30 minutes' \
--no-pager -o short-iso
sudo journalctl -k --since '-30 minutes' --no-pager -o short-iso
NRestarts вместе с журналом помогает обнаружить цикл автоматических перезапусков. Работающий сейчас процесс может уже быть заменой упавшему. Свойства systemctl относятся к текущему или сохранённому последнему запуску; предыдущие ищите в журнале. Сохраните нужный интервал до перезагрузки машины. Проверка ядра показывает журнал текущей загрузки с учётом прав и сохранившихся записей. Отсутствие вывода не исключает OOM.
Найдите ExecStart, рабочий каталог, пользователя, переопределения HOME и обновление через ExecStartPre, если оно есть. Сохраните материалы приватно. Перед публикацией уберите пароли, токены, адреса и сведения об игроках из unit-файла и журналов.
Найдите исходную ошибку игры#
Для указанной установки проверьте игровой журнал:
sudo tail -n 200 /home/satisfactory/server/FactoryGame/Saved/Logs/FactoryGame.log
sudo ls -lt /home/satisfactory/server/FactoryGame/Saved/Crashes
Это распространённые пути относительно установки из справочника файлов сервера, а не обязательные адреса для любой сборки. Если каталога нет, проверьте фактическое место запуска и консольный вывод. Ищите причину раньше последних строк: завершение отправителя отчёта об ошибке не объясняет, почему изначально упала игра.
Ошибка выделения памяти, assertion, отсутствующая библиотека и запрет записи требуют разных действий. Сопоставьте первую существенную ошибку со временем в журнале службы и ядра. Если служба завершена сигналом без игрового стека, сначала выясните причину со стороны хоста. Один SIGKILL или код оболочки 137 ещё не доказывает срабатывание OOM killer: процесс мог остановить администратор или обработчик тайм-аута.
Разделите память хоста и ограничение службы#
free -h
sudo systemctl show satisfactory.service \
-p MemoryCurrent -p MemoryPeak -p MemoryHigh -p MemoryMax \
-p EffectiveMemoryMax -p ControlGroup
Колонка available в free оценивает доступную память для новой работы. Низкое значение free само по себе может объясняться кешем. Это состояние сейчас, а не в момент падения. При контролируемом воспроизведении снимайте ряд значений: один замер не позволяет объявить утечку памяти.
Процесс может упираться в лимит службы или родительского slice, когда у хоста ещё есть свободная память. Документация systemd описывает жёсткую границу MemoryMax и влияние более строгого ограничения выше по иерархии. Набор свойств зависит от версии systemd и включённого учёта ресурсов. Пустое значение не означает, что ограничений нет.
На машине с cgroup v2 возьмите непустой путь ControlGroup и проверьте соответствующий memory.events, пока группа существует. Сравните счётчики до и после одного сбоя. Документация ядра различает нехватку при выделении (oom) и реально убитые процессы (oom_kill). Счётчики накопительные и могут учитывать потомков: изменение нужно связать с нужным экземпляром и временем. После удаления группы прочитать её уже не получится.
При подтверждённом ограничении меняйте конфигурацию владельца лимита — службы или контейнера — после проверки запаса для ОС и соседних задач. Бездумно снимать все границы не стоит. Если исчерпана память всей машины, уберите конкурирующую нагрузку или добавьте ресурсы по измеренным пикам, включая загрузку и сохранение мира. Swap меняет поведение при дефиците, но не делает диск равноценной оперативной памятью и не исправляет ошибку игры.
Проверьте место и права записи#
Сохранения и журналы установки могут находиться на разных файловых системах:
sudo df -h /home/satisfactory/server /home/satisfactory/.config/Epic/FactoryGame/Saved
sudo df -i /home/satisfactory/server /home/satisfactory/.config/Epic/FactoryGame/Saved
sudo -u satisfactory test -w /home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
Свободные блоки и inode проверяются отдельно: новые файлы перестают создаваться и при исчерпании inode, даже если байты ещё свободны. Проверка доступа ничего не печатает — смотрите код завершения. Она подтверждает права каталога, но не успешный сейв, доступную квоту или исправность диска.
Если путь отсутствует, сначала уточните HOME службы. При Permission denied проверьте конкретный файл и родительские каталоги; рекурсивная смена прав на весь домашний каталог обычно слишком широкое действие. При заполненном диске перенесите нужные журналы и архивы на другую машину, затем удаляйте только найденные ненужные данные. Сохраните последний рабочий checkpoint и копию текущего состояния.
Проверьте исправление на исходном сценарии#
Меняйте одну причину за раз. Перед воспроизведением сохраните проблемный checkpoint по инструкции резервного копирования. Если служба постоянно перезапускается, сначала соберите сведения, затем остановите именно её на время обслуживания. Перед правкой файлов убедитесь, что процесс завершился.
Если экземпляром управляет Nexardo на вашей Linux-инфраструктуре, выполняйте операции через его средства управления и сопоставляйте журнал экземпляра с данными хоста. Для проверки сохраните исходную нагрузку.
Запустите нужный экземпляр, проследите новый журнал и повторите исходное действие: загрузку, вход или сохранение. Проверьте фабрику, создайте новый сейв, выполните штатный перезапуск и подключитесь снова. На всём интервале наблюдайте запас хоста и предел службы. Просто работающий процесс без прежней нагрузки ещё не подтверждает исправление.
Если падение повторяется без признаков OOM или сбоя диска, сохраните первую ошибку игры, сборку, ветку, checkpoint и шаги воспроизведения. Проверяйте копию мира в отдельном совместимом экземпляре; заменять рабочую фабрику новым миром для эксперимента не нужно. Отправьте очищенный от секретов отчёт через страницу поддержки Coffee Stain. Похожая жалоба помогает найти направление, но её обходное решение не обязательно подходит вашей сборке.
