Логи и краш-репорты: как читать и искать причину

MAATRIX GAMES

Сервер лёг посреди вайпа, игроки пишут в дискорд «всё упало», а вы смотрите на пустой чёрный экран консоли и не понимаете, с чего начать. Хорошая новость: почти всегда причина крашка написана открытым текстом — просто не в том месте, куда вы обычно смотрите. В этой статье — рабочая методика: где лежат логи у большинства игровых серверов, что искать в первую очередь, чем краш-репорт отличается от обычного лога и как по типичным фразам в тексте ошибки понять, с чем вы имеете дело — не гадая и не переустанавливая сервер с нуля на всякий случай.

Где лежат логи: карта путей для разных типов серверов

Общий паттерн для подавляющего большинства игр — папка logs/ рядом с исполняемым файлом сервера. Дальше начинаются нюансы по движкам:

• Minecraft (Java, ваниль/Forge/Fabric/Paper) — logs/latest.log в корне сервера, старые сессии архивируются в logs/2026-08-28-1.log.gz. Отдельно crash-reports/ для настоящих крашей JVM.
• Source-движок (CS2, TF2, Left 4 Dead 2, Garry's Mod) — консоль сервера обычно ничего не пишет в файл по умолчанию, нужно включить логирование командой log on и sv_logfile 1, тогда файлы появятся в logs/L<дата>.log.
• ARK: Survival, ARK: Survival Ascended — ShooterGame/Saved/Logs/ShooterGame.log, там же лежат логи RCON-команд, если включён RCONEnabled.
• Project Zomboid — папка Zomboid/Logs/ (в профиле пользователя или рядом с сервером, зависит от ОС), внутри сразу несколько типов: *_DebugLog-server.txt, *_cmd.txt, *_chat.txt — краш чаще всего виден именно в DebugLog.
• 7 Days to Die — как Unity-игра, пишет output_log__<timestamp>__.txt в папке 7DaysToDieServer_Data, плюс отдельные Unity crash-дампы при настоящем падении процесса.
• Rust — вывод идёт в консоль (stdout), поэтому если сервер запущен через screen или tmux, лог живёт только в буфере сессии — стоит сразу настроить перенаправление в файл (./RustDedicated ... > server.log 2>&1). Отдельно логи плагинов Oxide/uMod — в oxide/logs/.
• Valheim — тоже пишет в stdout, встроенного файла лога нет. На Linux удобнее всего смотреть через journalctl -u valheim -f, если сервер запущен как systemd-юнит, либо через nohup ./valheim_server.x86_64 ... > valheim.log 2>&1 &.

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

Первый диагностический проход: что смотреть в первую очередь

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

1. Откройте файл и сразу прыгайте в конец (tail -n 200 logs/latest.log в консоли или Ctrl+End в текстовом редакторе).
2. Ищите последние 30-50 строк перед моментом остановки — именно там обычно лежит причина, а не в начале файла.
3. Прогоните файл через grep по ключевым словам:

grep -iE "exception|error|fatal|crash|out of memory|corrupt" logs/latest.log

1. Обратите внимание на самую первую ошибку в цепочке, а не на последнюю. Часто одна первопричина порождает каскад из десятка вторичных исключений — чинить нужно именно первую.
2. Зафиксируйте точное время краша (метка в логе) и сверьте с системными логами хоста — если сервер упал одновременно с рестартом контейнера или OOM-killer'ом ОС, дело вообще не в игре.

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

diff logs/2026-08-27-1.log logs/latest.log | less

Краш-репорты: чем они отличаются от обычного лога

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

У Minecraft это crash-reports/crash-2026-08-29_14.32.05-server.txt — в шапке файла сразу видно версию Minecraft, версию Forge/Fabric Loader и полный стек вызовов. Ищите там строку Caused by: — это и есть корень проблемы, а не первая строка исключения (она обычно просто «что-то пошло не так на уровне выше»).

У Unity-игр (7 Days to Die, Valheim при использовании BepInEx) краш-дампы обычно попадают в системную папку логов Unity — на Linux это, как правило, ~/.config/unity3d/<Studio>/<Game>/, на Windows — %USERPROFILE%\AppData\LocalLow\<Studio>\<Game>\. Точный путь зависит от игры и версии Unity, поэтому если не нашли с первого раза — поищите файлы Player.log или output_log*.txt рядом.

Главное правило: если есть отдельный краш-репорт — читайте сначала его, а не обычный лог. В обычном логе часто просто обрывается вывод («сервер завис/умер»), а причина видна только в стектрейсе краш-репорта.

Нехватка памяти в логах: как это выглядит

OOM (out of memory) — одна из самых частых причин падений, особенно на модовых сборках Minecraft и серверах с большим количеством плагинов. В логах она проявляется по-разному:

• Java: java.lang.OutOfMemoryError: Java heap space или GC overhead limit exceeded — сборщик мусора тратит почти всё время на попытки освободить память, вместо реальной работы.
• Общесистемный OOM-killer Linux убивает процесс молча — в логе игры вы увидите просто резкий обрыв без финальной ошибки, а причину нужно смотреть в dmesg | grep -i oom или journalctl -k | grep -i "out of memory".
• Unity/Source: чаще похоже на Fatal error: Allocation failed или bad_alloc — сигнал, что процессу не хватило оперативной памяти под текущую нагрузку (число игроков, размер карты, кэш чанков).

Практический вывод: если OOM повторяется регулярно, а не разово — это почти всегда не баг, а нехватка выделенной серверу RAM под конкретную сборку. Стоит свериться с рекомендуемым объёмом для игры (для тяжёлых модпаков Minecraft это часто 6-8 ГБ, а не стандартные 2 ГБ под ваниль) и, если нужно, оптимизировать TPS и настройки самих модов, прежде чем просто накидывать память — иногда проблема не в объёме, а в утечке конкретного мода.

Конфликты модов и плагинов: как вычислить виновника

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

1. В стектреке Java ищите имя пакета мода/плагина — оно почти всегда видно в пути класса, например at com.someauthor.modname.EventHandler.onTick. Это и есть подозреваемый.
2. Если в стеке фигурируют сразу несколько модов — проблема, скорее всего, на стыке (оба меняют одну и ту же механику, например хук на генерацию мира или на инвентарь).
3. Для плагинных серверов (Paper, Oxide/uMod, ESX/QBCore для FiveM) — включайте логирование по плагинам отдельно, если фреймворк это поддерживает: у Oxide это oxide/logs/<plugin>/, у Paper — таймингс через /timings report.
4. Метод исключения одного мода/плагина за раз всё ещё надёжнее всего, если стектрейс неоднозначный: отключаете половину списка, воспроизводите краш, делите пополам оставшихся — классический бинарный поиск виновника, минут 15-20 на сборку из 40-50 модов.
5. Проверьте версии — конфликт часто вылезает не из-за самих модов, а из-за несовпадения версий загрузчика (Forge/Fabric) и требуемой версии API у конкретного мода. Это отдельно видно в шапке краш-репорта.

Если работаете с Rust-плагинами на Oxide/uMod, полезно сразу настроить логирование самих плагинов при установке — тогда при следующем краше не придётся включать его в панике посреди вайпа.

Повреждённые сохранения и сетевые ошибки

Два других частых виновника, которые тоже узнаются по характерным фразам в логе:

Повреждённый файл сохранения — обычно это NBTException, Corrupted world, Failed to load chunk, Unexpected end of file или похожие сообщения при чтении файла мира/базы. Часто возникает после жёсткого выключения питания хоста, killed-процесса без штатного сохранения или переполненного диска в момент записи. Первая помощь — проверить свободное место (df -h), затем попробовать откатиться на предыдущий бэкап, если он есть, вместо попыток руками чинить бинарный файл сохранения.

Сетевые ошибки — Connection reset by peer, Socket timeout, EADDRINUSE (порт уже занят другим процессом), Failed to bind to port. Последнее особенно частое — обычно значит, что предыдущий процесс сервера не завершился штатно и всё ещё держит порт. Проверяется командой lsof -i :<порт> или netstat -tulnp | grep <порт> на Linux.

Отдельная категория — обрывы у игроков (не у сервера): если в логе массово появляются disconnect: timed out в моменты пиковой нагрузки, это чаще говорит о нехватке тикрейта/CPU на сервере, а не о проблемах с сетью у игроков — сервер просто не успевает отвечать на keep-alive пакеты.

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