Краш-репорты Minecraft: watchdog и лаги

Краш-репорт сервера Minecraft - это текстовый файл в crash-reports/, где записано, что сервер делал в момент падения: исключение, трассировка стека и - часто - точная сущность или блочная сущность, которая тикала, с её координатами. Читайте три вещи по порядку: строку Description, первые строки трассировки стека в поисках имени пакета, которое не принадлежит Minecraft или Paper, и раздел «being ticked», если он есть. В большинстве случаев этого хватает, чтобы найти причину. Остановки из-за лагов устроены иначе: их вызывает watchdog, он пишет в лог дамп потоков вместо краш-файла, и читать его нужно, глядя на то, на чём застрял основной поток. А предупреждение «Can't keep up» и вовсе не краш.

Статья о серверах Paper и ванильных серверах. Модовые серверы выдают такие же отчёты, только длиннее, - особенности Forge, NeoForge и Fabric разобраны в статье модовый сервер без крашей.

Три разновидности «сервер упал»#

Одним словом называют три разных события, и каждое оставляет разные улики.

Больше всего путает третий случай. Если лог просто обрывается на полуслове, без краш-репорта и сообщений об остановке, процесс Java не упал - его завершили. Обычная причина на хостинге - достижение лимита памяти: контейнер останавливает ядро, и у Java нет шанса что-либо записать. В RE:NODE сервер, упёршийся в лимит памяти, останавливается и чисто перезапускается, а не уходит в своп, и график памяти в панели показывает, как он доходит до черты прямо перед этим. Что происходит в этот момент, объясняется в статье своп в Linux и OOM killer, а если это повторяется - в статье почему игровой сервер постоянно перезапускается.

Из чего состоит краш-репорт#

Структура краш-репорта всегда одинакова. Вот сокращённый пример:

---- Minecraft Crash Report ----// Shall we play a game?Time: 2026-10-07 21:14:03Description: Ticking entityjava.lang.NullPointerException: Cannot invoke "org.bukkit.Location.getWorld()" because "loc" is null    at com.example.petsplus.PetTask.follow(PetTask.java:88)    at com.example.petsplus.listener.PetListener.onMove(PetListener.java:41)    at net.minecraft.world.entity.Entity.tick(Entity.java:...)    ...A detailed walkthrough of the error, its code path and all known details is as follows:----------------------------------------------------------------------------------------- Head --Thread: Server thread-- Entity being ticked --Details:    Entity Type: minecraft:wolf    Entity's Exact location: -412.50, 64.00, 1290.31...-- System Details --Details:    Minecraft Version: 1.21.x    Java Version: 21.0.x    Memory: 2140000000 bytes (2040 MiB) / 4294967296 bytes (4096 MiB) up to ...    JVM Flags: ...

Что сообщает каждая часть:

• Комментарий под заголовком - случайная шутка. Не обращайте внимания.
• Description - категория: Ticking entity, Ticking block entity, Exception in server tick loop, Watching Server, Exception generating new chunk. По ней понятно, в каком разделе ниже будут координаты.
• Строка исключения - тип и сообщение. NullPointerException, ConcurrentModificationException, StackOverflowError, OutOfMemoryError и ClassCastException покрывают большинство случаев.
• Трассировка стека - цепочка вызовов методов, которая привела к ошибке, самый свежий вызов сверху.
• Раздел «being ticked» - для крашей при тике тип сущности или блока и его точное расположение. Это золото: он говорит, где в мире проблема.
• System Details - версия Minecraft, версия Java, память на момент краша, флаги JVM. Смотрите сюда каждый раз, когда краш кажется необъяснимым: неправильная версия Java или крошечный heap многое объясняют.

Как читать трассировку стека#

Трассировка стека перечисляет вызовы методов, и тот, что упал, находится сверху. Каждая строка выглядит как at package.Class.method(File.java:line). Чтобы ей пользоваться, не нужно быть программистом; нужно узнавать имена пакетов.

1. Читайте сверху вниз и остановитесь на первой строке, которая не относится к игре. Собственный код Minecraft находится в net.minecraft, Paper и Bukkit - в io.papermc, org.bukkit и org.spigotmc, сама Java - в java. и jdk.. Первый кадр за пределами этих пакетов обычно и есть виновник. В примере выше com.example.petsplus - плагин, и он на самом верху.
2. Ищите «Caused by:». Исключения часто обёрнуты: верхнее говорит «ошибка при тике», а настоящее лежит ниже, в Caused by:. Последний Caused by: в цепочке - первопричина; читайте его первые кадры тем же способом.
3. Сопоставьте пакет с плагином. В имени пакета обычно есть название плагина или автора. Если не очевидно, поищите в папке plugins/: plugin.yml или paper-plugin.yml каждого jar называет его главный класс, который начинается с того же пакета.
4. Запишите версию. Что бы вы ни отправляли автору плагина, приложите версию плагина, сборку Paper и полный краш-репорт, а не скриншот последних десяти строк.

Если весь стек внутри net.minecraft и в нём нет ни одного кадра плагина, краш произошёл в самой игре или вызван плохими данными в мире - повреждённой сущностью или чанком. Тогда самой полезной частью отчёта становятся координаты из «being ticked»; что с ними делать, разобрано в статье повреждённые чанки и файлы регионов.

Ошибки, которые попадают в лог, но не роняют сервер#

Не каждая трассировка стека - краш. Ошибки плагинов часто перехватываются и записываются в лог, а сервер продолжает работать. Два сообщения Bukkit стоит узнавать в лицо:

[ERROR]: Could not pass event PlayerInteractEvent to ShopKeeperX v2.4.1org.bukkit.event.EventException: null    ...Caused by: java.lang.NullPointerException: ...

[ERROR]: Error occurred while enabling WarpsPlus v1.3 (Is it up to date?)java.lang.NoSuchMethodError: ...

В консоли они выглядят пугающе, но значат разное:

• «Could not pass event X to Y» - плагин Y выбросил исключение, обрабатывая событие. Эта функция плагина для этого действия сломана; с сервером всё в порядке. Читайте строку Caused by.
• «Error occurred while enabling X (Is it up to date?)» - плагин не смог запуститься, обычно потому, что собран под другую версию Minecraft или ему не хватает зависимости. Плагин отключён.

Тип ошибки Java часто говорит о характере проблемы ещё до того, как вы будете читать дальше:

Сообщения UnsupportedClassVersionError называют версию class-файла: 61.0 означает, что коду нужна Java 17, 65.0 - Java 21. Если Java на сервере старше, код не загрузится. Таблица версий - в статье флаги JVM и версии Java.

OutOfMemoryError заслуживает отдельного пояснения, потому что его сообщение говорит, какая именно память закончилась. Java heap space означает, что heap, заданный через -Xmx, заполнен: либо он слишком мал для мира и плагинов, либо что-то течёт и heap заполнился бы при любом размере. GC overhead limit exceeded - та же проблема со стороны сборщика мусора: он тратит почти всё время на то, чтобы освободить почти ничего. Metaspace - это метаданные классов, и на сервере с плагинами это обычно указывает на плагин, который многократно перезагружают через /reload или менеджер плагинов, отчего старые копии всех классов утекают. Ошибка heap - не повод поднимать -Xmx до полного объёма тарифа: JVM нужна память и вне heap, а heap, выставленный впритык к лимиту контейнера, превращает ошибку Java с отчётом в убийство процесса вообще без отчёта.

«Can't keep up!» - это предупреждение, а не краш#

[WARN]: Can't keep up! Is the server overloaded? Running 5214ms or 104 ticks behind

Сервер стремится к 20 тикам в секунду, по 50 мс на тик. Когда он отстаёт от графика больше чем на пару секунд, он пишет это сообщение и пропускает упущенные тики, а не пытается их наверстать. Сообщение означает, что какое-то время сервер не успевал сделать 50 мс работы за 50 мс.

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

• Что-то дорогое в основном потоке: слишком много сущностей, ферма, генерация чанков, медленный плагин.
• Паузы сборки мусора из-за слишком маленького heap или плохо подобранных флагов.
• Нехватка CPU, когда процесс не получает достаточно процессорного времени. У хостера с жёсткими лимитами CPU сервер, которому нужно больше его доли, троттлится, и выглядит это точь-в-точь как лаги.

Число отставших тиков - не оценка серьёзности, которую можно использовать напрямую; оно зависит от того, насколько долгим был простой. Чтобы найти настоящую причину, используйте spark, а типичные исправления описаны в статье почему падает TPS.

Watchdog: когда сервер перестаёт отвечать#

Если один тик длится слишком долго, сервер считает, что основной поток застрял навсегда, и выключается сам. Это и есть watchdog. Настроек две, одна из ванильной игры, другая из Spigot:

max-tick-time=60000

settings:  timeout-time: 60  restart-on-crash: true  restart-script: ./start.sh

Что делает каждая из этих настроек и что лучше не трогать:

• max-tick-time - ванильный watchdog, в миллисекундах. Если один тик длится дольше, сервер пишет краш-репорт с описанием Watching Server и останавливается. -1 отключает его - и превращает застрявший сервер в сервер, который висит вечно вместо перезапуска. Не делайте так.
• timeout-time - watchdog Spigot, в секундах. Paper по нему решает, когда вывести дамп потоков и остановиться.
• restart-on-crash и restart-script позволяют серверу запустить скрипт, чтобы перезапустить себя. У хостера с панелью оставьте перезапуск панели: пути к скрипту в контейнере обычно не существует.

Paper добавляет ранние предупреждения, которые настраиваются в config/paper-global.yml:

watchdog:  early-warning-every: 5000  early-warning-delay: 10000

Когда основной поток простоял early-warning-delay миллисекунд, Paper начинает выводить дамп потоков каждые early-warning-every миллисекунд, не убивая сервер. Это значит, что улики у вас будут, даже если сервер потом придёт в себя.

Как читать дамп потоков

[ERROR]: --- DO NOT REPORT THIS TO PAPER - THIS IS NOT A BUG OR A CRASH ---[ERROR]: The server has not responded for 10 seconds! Creating thread dump[ERROR]: ------------------------------[ERROR]: Server thread dump (Look for plugins here before reporting to Paper!):[ERROR]: Current Thread: Server thread[ERROR]:     PID: 27 | Suspended: false | Native: false | State: RUNNABLE[ERROR]:     Stack:[ERROR]:         com.example.claims.Storage.saveAll(Storage.java:212)[ERROR]:         com.example.claims.ClaimsPlugin.onAutosave(ClaimsPlugin.java:77)[ERROR]:         org.bukkit.craftbukkit.scheduler.CraftTask.run(...)

Точная формулировка зависит от версии Paper. Важен стек «Server thread»: он показывает, что делал основной поток в момент дампа. Читайте его сверху вниз точно так же, как трассировку краша. В примере плагин приватов синхронно сохраняет все свои данные в основном потоке, и это баг или проблема настройки этого плагина.

Если несколько дампов подряд показывают одни и те же кадры, это и есть застрявший код. Если каждый раз кадры разные, поток занят, а не застрял, - как правило, это перегрузка, и профайлер покажет её лучше дампов. Если в стеке видно обращение к базе данных или сети (java.net, jdbc, SocketInputStream), плагин ждёт чего-то удалённого из основного потока; почему это больно, объясняется в статье MySQL для плагинов.

Нативные краши и файлы hs_err#

Очень редко падает сама виртуальная машина Java. Она пишет файл с именем hs_err_pid<number>.log в рабочую папку сервера, а лог резко обрывается. Причины - баг JVM, нативная библиотека из плагина или проблемы с оборудованием. Первое, что стоит попробовать, - актуальная сборка Java нужной основной версии; второе - удалить плагины, которые несут с собой нативный код. Такие краши настолько редки, что каждый стоит расследовать, а не игнорировать.

Порядок действий при любом краше#

1. Соберите улики, прежде чем снова перезапускать. Скопируйте logs/latest.log и все новые файлы в crash-reports/. Перезапуск ротирует лог.
2. Определите тип: краш-репорт, дамп watchdog или лог, который просто обрывается.
3. Найдите первый кадр не из игры в стеке или координаты в разделе «being ticked».
4. Измените одну вещь: обновите или удалите этот плагин либо разберитесь с этой сущностью или чанком. Потом наблюдайте.
5. Если краш повторяется с разными причинами, ищите общие факторы: память, версия Java, недавнее обновление.

В RE:NODE специальный наблюдатель считает краши: перезапуски, которые вы запросили сами, не учитываются, но три незапланированных за час выводят предупреждение на странице сервера и автоматически открывают тикет, а шесть приостанавливают сервер, пока его не посмотрят. Это повод относиться к циклу крашей как к срочной проблеме, а не позволять серверу перезапускаться всю ночь. Консоль панели показывает полный нефильтрованный вывод, так что улики для шага 1 доступны, даже если сервер не держится запущенным.

FAQ#

Где сохраняются краш-репорты сервера Minecraft?

В папке crash-reports в корне сервера, с датой и временем в имени и окончанием -server.txt. Дампы watchdog и ошибки плагинов находятся в logs/latest.log, а более старые логи лежат сжатыми в logs/.

Почему при остановке сервера нет краш-репорта?

Потому что его остановили снаружи процесса Java, обычно за превышение лимита памяти. Когда Java убивают, она не может записать отчёт. Посмотрите график памяти в районе времени остановки.

Опасно ли «Can't keep up»?

Само по себе нет. Оно означает, что сервер отстал и пропустил тики. Постоянные предупреждения означают настоящие лаги, которые чувствуют игроки, и причину нужно искать, но миру это предупреждение не вредит.

Отключить ли watchdog, чтобы сервер перестал падать?

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

В краш-репорте упоминаются только классы Minecraft. Это баг Paper?

Возможно, но чаще это плохие данные в мире, например повреждённая сущность, или плагин, последствия работы которого проявляются позже в ванильном коде. Проверьте координаты из «being ticked» и протестируйте без плагинов, прежде чем сообщать об этом разработчикам.