Что делать, если сервер упал: чек-лист диагностики

MAATRIX GAMES

Сервер упал, в Discord уже пишут "сервак лежит", а ты открываешь консоль и не знаешь, с чего начать. Знакомая ситуация — паника заставляет хвататься то за логи, то за рестарт, то за конфиги, и в итоге время уходит впустую. Ниже — чек-лист, который работает для любой игры (Minecraft, Rust, CS2, ARK, да хоть текстовый MUD): идём от самого простого и вероятного к сложному, чтобы не копать глубоко там, где хватило бы одной команды.

Шаг 1: жив ли сам хост

Первым делом проверяем не игровой сервер, а сам VPS — потому что если хост недоступен, разбираться в логах игры бессмысленно.

ping your.server.ip
ssh user@your.server.ip

Если пинг не идёт и SSH не пускает — проблема на уровне хостинга, а не игры: упал сам сервер, перезагрузился хост-нод, сработал файрвол, закончился трафик по лимиту, или провайдер что-то чинит на своей стороне. В этом случае никакие манипуляции с игровым процессом не помогут — нужно смотреть панель провайдера или писать в поддержку.

Отдельный частый случай: пинг идёт, но SSH не пускает (connection refused или timeout). Это может значить, что sshd упал или завис — тогда доступ через веб-консоль хостинга (VNC/serial console в панели) обычно ещё работает, даже когда SSH недоступен. У MAATRIX GAMES, как и у большинства провайдеров VPS, такая консоль есть в личном кабинете — используй её как запасной вход, если по SSH достучаться не получается.

Если хост живой и SSH пускает — идём дальше, проблема локальная, на уровне процесса или самой игры.

Шаг 2: запущен ли процесс сервера

Дальше смотрим, жив ли вообще процесс игры. Если сервер настроен через systemd (о том, как это сделать правильно, есть отдельная статья про автоматический рестарт по расписанию), первая команда:

systemctl status minecraft-server.service

Смотрим на статус: active (running) — процесс жив, проблема не в падении сервиса, а в чём-то другом (сеть, порт, конфиг). failed или inactive (dead) — сервис действительно упал, и systemd сам его не поднял (если, конечно, в юните не настроен Restart=on-failure).

Если systemd не используется и сервер запущен вручную (screen, tmux или просто в фоне через nohup), ищем процесс напрямую:

ps aux | grep java        # для Minecraft
ps aux | grep srcds       # для CS2/Source-игр
ps aux | grep -i rust     # для Rust
screen -ls                # список активных screen-сессий
tmux ls                   # список активных tmux-сессий

Если процесса нет в списке — сервер действительно упал (crashed), а не завис. Если процесс есть, но игроки не могут зайти — это уже не падение, а зависание или проблема с сетью/портами, и чек-лист диагностики будет немного другим.

Шаг 3: последние строки лога перед падением

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

tail -n 200 logs/latest.log        # Minecraft (Paper/Spigot/Vanilla)
tail -n 200 console.log            # многие другие игры
journalctl -u minecraft-server.service -n 200 --no-pager   # если через systemd

Смотрим на самое последнее, что успело записаться — обычно там либо явная ошибка (stack trace, exception), либо лог просто обрывается на полуслове (что часто означает OOM-килл или kill -9 со стороны системы). Ключевые вещи, на которые стоит обратить внимание:

• OutOfMemoryError — не хватило выделенной памяти (Java-heap для Minecraft, например)
• NullPointerException в стектрейсе конкретного плагина/мода — виновник почти наверняка он
• EOFException или обрыв соединения с базой данных — проблема с внешним сервисом (MySQL, Redis)
• Полное отсутствие ошибки, лог просто обрывается — почти всегда это внешнее убийство процесса (OOM-killer системы, а не самой игры)

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

Шаг 4: ресурсы хоста

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

free -h
df -h

Если free -h показывает, что вся память забита, а available близко к нулю — вот и причина: системный OOM-killer прибил процесс сервера, чтобы не уронить всю машину. Особенно часто это бывает у модовых Minecraft-сборок (Forge/Fabric с десятками модов легко съедают выделенный -Xmx, а если ещё и хост загружен другими процессами — killer сработает раньше, чем ожидаешь).

Если df -h показывает 100% на разделе с игровыми файлами — сервер может падать при попытке записать world-файл, лог или бэкап, и это тоже классика, особенно на серверах, где давно не чистились старые логи или бэкапы. Быстрая проверка, что жрёт место:

du -sh /* 2>/dev/null | sort -rh | head -n 10

Если регулярно упираешься в диск из-за бэкапов, которые накапливаются локально, стоит настроить их ротацию и хранение вне сервера — как это сделать, разобрано в статье про автобэкапы и расписание.

Отдельно стоит взглянуть на нагрузку CPU в момент падения (top или htop), но на практике падения от перегрузки CPU без сопутствующей OOM-ситуации встречаются заметно реже.

Шаг 5: перезапуск и наблюдение за стабильностью

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

systemctl restart minecraft-server.service
systemctl status minecraft-server.service
journalctl -u minecraft-server.service -f

Флаг -f в journalctl держит лог "живым" — так сразу видно, если сервер снова падает при старте. Дайте серверу поработать минимум 15-30 минут под нагрузкой (с реальными игроками, если есть возможность), прежде чем считать проблему решённой. Многие падения проявляются не сразу при старте, а спустя время — например, при накоплении сущностей в мире, при первом полном автосохранении или когда на сервер заходит определённое количество игроков одновременно.

Если под рукой нет времени детально разбираться, а сервер нужно поднять прямо сейчас — временный рестарт без анализа причины это нормальная тактика (сервер снова заработает), но проблема почти наверняка повторится позже. Считайте это первой помощью, а не лечением.

Шаг 6: если падение повторяется — искать закономерность

Если сервер падает не один раз, а систематически, разовая диагностика превращается в поиск паттерна. Стоит зафиксировать (например, в отдельном текстовом файле или таблице) несколько падений подряд и сравнить:

• Время — падает всегда примерно в одно и то же время суток? Возможно, это совпадает с cron-задачей (авто-бэкап, авто-рестарт) или с пиком онлайна.
• Действие игроков — падение происходит при заходе на определённую локацию, использовании конкретного предмета/команды, или при массовом заходе после рестарта (login storm)?
• Конкретный мод/плагин — можно временно отключать плагины/моды по одному (бинарный поиск: отключить половину, проверить, сузить круг) и смотреть, пропадают ли падения.
• Версия игры/сборки — не совпало ли начало падений с недавним обновлением сервера, плагина или мода? Если да — откат к предыдущей версии может быть быстрее, чем поиск бага.

Для мониторинга TPS и общей нагрузки в реальном времени, чтобы ловить деградацию до того, как она приведёт к полному краху, полезно настроить постоянное наблюдение — этому посвящена статья про мониторинг TPS и лагов. Она особенно полезна, когда сервер не падает резко, а постепенно деградирует перед крашем.

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