Paper reagiert nicht: Belege für die Watchdog-Analyse sichern

Wenn Paper nicht mehr reagiert und eine Watchdog-Warnung ausgibt, sichere das Protokoll des Vorfalls und prüfe, ob der Prozess noch läuft. Bereite anschließend eine kontrollierte Reproduktion vor, bevor du Zeitlimits änderst. Zunächst geht es darum, einen bekannten Betriebszustand wiederherzustellen und die nötigen Informationen für die Untersuchung zu erhalten. Ein erfolgreicher Neustart allein belegt keine Fehlerbehebung.

Dieser Leitfaden richtet sich an Verantwortliche bestehender Communitys und Teams, die einen Vorfall an ihren Betreiber oder Entwickler übergeben müssen. Er behandelt längere Blockaden auf Paper. Ablauf und Beispiel sind Vorschläge für die Zusammenarbeit, keine von Mineando durchgeführten Tests. Sie lassen sich nicht ungeprüft auf Folia oder einen Server mit Mods übertragen.

Warnung und Prozessende auseinanderhalten

Laut Paper kann eine Watchdog-Warnung auf einen stark verzögerten Tick hinweisen, während der Prozess weiterläuft. Ein Thread-Dump zeigt, wo ein Thread in diesem Moment ausgeführt wurde. Das kann die Untersuchung eingrenzen, legt aber nicht immer die Ursache offen. Siehe die Dokumentation zur Fehlersuche.

Halte drei Beobachtungen getrennt fest: Was haben Spieler erlebt, was hat der Server protokolliert und was hat die Prozessverwaltung getan? Ein Screenshot der letzten Zeile lässt die Abfolge dazwischen offen.

Beobachtung	Vorgeschlagene erste Prüfung
Warnungen erscheinen, der Prozess läuft weiter	Festhalten, ob und wann der Server wieder reagiert; ein laufender Prozess genügt als Nachweis nicht
Nach den Warnungen endet der Prozess	Das Protokollende sichern und klären, welche Komponente Stopp oder Neustart ausgelöst hat
Der Prozess verschwindet ohne vorherige Warnung	Ereignisse von Host und Prozessverwaltung beim Betreiber anfordern; die Ursache zunächst offenlassen

Ordne nicht jede getrennte Verbindung dem Watchdog zu. Verknüpfe jede Beobachtung mit einer Uhrzeit und einer nachvollziehbaren Quelle.

Einen Vorfallsbericht sichern, bevor weitere Änderungen folgen

Eine benannte Person sollte den Vorfall koordinieren und Eingriffe dokumentieren. Bleibt der Dienst blockiert, folgt ihr dem mit dem Betreiber vereinbarten Ablauf für Abschaltung oder Wiederherstellung. Verlängert den Ausfall nicht unbegrenzt, nur um eine perfekte Aufzeichnung zu erhalten.

Lege folgende Informationen in einem datierten Ordner mit einer Vorgangsnummer ab:

• Das Protokoll des betroffenen Serverlaufs, vollständige Warnungen und die Einträge davor und danach. Dazu gehören gegebenenfalls rotierte Protokolle.
• Uhrzeit mit Zeitzone, beobachtete Dauer und Spieleraktionen unmittelbar vor dem Vorfall.
• Genaue Versionen von Minecraft, Paper, Java und Plugins sowie die letzte bekannte Änderung.
• Relevante Watchdog- und Neustarteinstellungen, ohne Kennwörter oder Schlüssel.
• Verfügbare Hostereignisse und Messwerte für diesen Zeitraum: Arbeitsspeicher, CPU, Speicherzugriffe und externe Abhängigkeiten.
• Jeden Eingriff mit Zeitpunkt und Ergebnis; kennzeichne ausdrücklich, welche Informationen fehlen.

Bewahre ein Original mit eingeschränktem Zugriff auf und erstelle eine geprüfte Kopie zur Weitergabe. Entferne sensible Angaben, ohne die brauchbaren Teile der Aufrufkette zu verlieren. Ein vollständiges Serververzeichnis oder Zugangsdaten zur Datenbank werden nicht benötigt, um die Blockade zu dokumentieren.

Falls ihr eine Wiederherstellung erwägt, benennt vorher den Wiederherstellungspunkt und den Spielstand, der dadurch verloren ginge. Eine Probe der Backup-Wiederherstellung bereitet diese Entscheidung vor. Sie erklärt jedoch nicht die Ursache des Vorfalls.

Ausbleibende Meldungen sind kein Reparaturnachweis

In Papers globaler Konfigurationsreferenz legt watchdog.early-warning-delay den Beginn der Thread-Dumps fest, early-warning-every ihren Abstand. Beide Angaben erfolgen in Millisekunden; dokumentierte Standardwerte sind 10000 und 5000. Prüfe die tatsächlich verwendeten Werte eurer Installation.

Die Referenz zu spigot.yml beschreibt settings.timeout-time in Sekunden sowie restart-on-crash und restart-script. Dieser Neustartmechanismus erfasst keine externe Beendigung durch das Betriebssystem. Kläre deshalb auch, welche weitere Komponente euren Prozess verwaltet.

Diese Einstellungen haben unterschiedliche Aufgaben. Halte vor einer Änderung den Ausgangszustand und die beabsichtigte Verhaltensänderung fest. Ein höheres Zeitlimit beweist nicht, dass die blockierende Operation schneller geworden ist.

Paper beschreibt außerdem disable.watchdog als Abschaltung des Warnsystems in der Referenz der Systemeigenschaften. Akzeptiere eine Reparatur nicht allein deshalb, weil diese Änderung die Meldungen verschwinden lässt. Benötigt eine Fachperson andere Einstellungen für die Untersuchung, begrenzt den Versuch und dokumentiert die spätere Betriebskonfiguration.

Aus der Aufrufkette eine überprüfbare Vermutung ableiten

Bitte die prüfende Person, den auffälligen Thread und die zu untersuchende Operation zu benennen. Sie sollte auch erklären, welche Informationen noch fehlen. Ein Pluginname in der Aufrufkette reicht nicht als Begründung, das Plugin zu entfernen. Verknüpft diesen Hinweis mit dem Zeitpunkt, beteiligten Abhängigkeiten und einer wiederholbaren Aktion.

Ein hypothetisches Beispiel: Um 19:42 öffnet jemand ein Belohnungsmenü. Danach erscheinen Warnungen, und das Spiel schreitet nicht mehr fort. Die Aufrufkette enthält Aufrufe dieser Funktion. Die Arbeitshypothese lautet, dass die Aktion an der Blockade beteiligt ist. Ob das Plugin, eine Abhängigkeit oder die Umgebung verantwortlich ist, steht damit noch nicht fest.

Wiederholt die Aktion auf einer isolierten Kopie mit denselben Versionen und einem repräsentativen Datenstand. Verhindert Schreibzugriffe auf produktive Datenbanken und Integrationen. Der Entwickler sollte eine einzelne kontrollierte Änderung vorschlagen; anschließend wird das Szenario wiederholt. Protokolliert Versuche mit und ohne Blockade. Ein erfolgreicher Durchlauf schließt einen sporadischen Fehler nicht aus.

Wenn ein zusätzliches Profil benötigt wird, plant dessen Aufzeichnung vor der Reproduktion. Papers Profiling-Dokumentation verlangt, dass das untersuchte Problem während der Aufzeichnung auftritt. Ein späteres Profil einer ruhigen Sitzung erklärt die frühere Blockade für sich genommen nicht.

Freigabe und offene Ursachen getrennt dokumentieren

Vereinbart vor dem erneuten Test das Szenario, die geplanten Wiederholungen, erwartete Ergebnisse und die entscheidungsbefugte Person. Ein wieder verfügbarer Dienst und eine bestätigte Fehlerursache sind getrennte Ergebnisse, die zu unterschiedlichen Zeitpunkten vorliegen können.

Fordere für die Abnahme das ursprüngliche Szenarioprotokoll, die vorgenommene Änderung und das Ergebnis der Wiederholung an. Prüft außerdem die betroffene Funktion: Im Beispiel sollte eine Belohnung genau einmal vergeben werden und ihr Zustand einen sauberen Neustart überstehen. Das sind vorgeschlagene Prüfkriterien für diesen Fall, keine allgemeinen Stabilitätsgarantien.

Erfordert die Korrektur ein Update, nutzt eine Entscheidung über Freigabe und Wiederherstellung mit eindeutig benannter Version und vorbereitetem Rückweg. Bleibt es bei einer Maßnahme zur Begrenzung der Auswirkungen, wird die Ursache weiterhin als offen geführt.

Für eine Prüfung eurer betreuten Minecraft-Infrastruktur benötigt Mineando den Vorfallsbericht, die Auswirkungen auf eure Community und das verfügbare Zeitfenster für Tests. Projekte sind kostenpflichtig und werden individuell vereinbart. Monitoring, Wartung und Unterstützung bei Vorfällen erhalten einen ausdrücklichen Leistungsumfang; eine Prüfung bedeutet keine dauerhafte Bereitschaft.