Fehlerbehebung

Fang mit service <name> logs für einen einzelnen Server und logs für die Cloud an. Fast jeder Fall unten kündigt sich in einem der beiden an.

Keine Node mit genug ArbeitsspeicherLink zum Abschnitt kopieren

Für Lobby steht keine Node mit genug Speicher bereit

Das Budget der Node ist aufgebraucht. Es ist ein Budget, keine Messung des Servers:

[resources]
memory = 4096
reserve = 1024

Server dürfen memory minus reserve nutzen. Setz memory auf das, was der Server wirklich hat, abzüglich dessen, was das Betriebssystem und deine Datenbanken brauchen, oder gib der Gruppe weniger pro Server. Gestartet wird erst wieder, wenn Platz ist, und das ist so gewollt: Die Alternative wäre ein Server im Swap.

Gruppendateien sind fehlerhaftLink zum Abschnitt kopieren

Gruppendateien sind fehlerhaft, es gilt weiter der letzte gültige Stand

Eine TOML-Datei unter groups/ lässt sich nicht einlesen. Die Cloud läuft mit dem letzten gültigen Stand weiter und ändert nichts. Korrigiere die Datei, der nächste Durchlauf übernimmt sie, ein Neustart ist nicht nötig.

JavaLink zum Abschnitt kopieren

Java-Pfad existiert nicht: /opt/jdk/bin/java
Nur 'temurin' wird automatisch geladen, 'zulu' braucht einen expliziten java.path

Laufzeitumgebungen werden pro Gruppe geholt und unter runtimes/ abgelegt. Automatisch heruntergeladen wird nur Temurin. Jede andere Distribution muss auf dem Server vorhanden sein und ausdrücklich angegeben werden:

[java]
path = "/usr/lib/jvm/java-8-openjdk-amd64/bin/java"

Ein Server stürzt abLink zum Abschnitt kopieren

Bench-3 ist abgestürzt (Code 137)
Absturzbericht von Bench-3 gesichert unter dumps/Bench-3-1790120833

Code 137 bedeutet, dass der Prozess beendet wurde, meistens vom Out-of-Memory-Killer des Kernels. Gib der Gruppe mehr Arbeitsspeicher oder dem Server weniger Spielserver. Der Bericht unter dumps/ enthält die letzte Ausgabe. Die neuesten dumps_keep davon bleiben erhalten, eingestellt unter [logs], standardmäßig dreißig.

Ein Server hängtLink zum Abschnitt kopieren

Lobby-1 reagiert nicht mehr: Seit 95s kein Lebenszeichen vom Hauptthread

Der Prozess lebt, aber sein Hauptthread tickt nicht mehr. Der Watchdog ersetzt den Server. Passiert das öfter, schau dir das Log des Servers kurz vor dem Stillstand an: Ein Plugin in einer Endlosschleife, eine Lastspitze bei der Weltgenerierung oder ein Garbage Collector in Not sehen von außen alle so aus.

[watchdog]
hang_seconds = 90
restart = true

Ein Server lässt sich nicht stoppenLink zum Abschnitt kopieren

Lobby-1 reagiert nicht auf den Stopp-Befehl, wird jetzt beendet

Der Server sollte herunterfahren, hat das innerhalb der Wartezeit nicht getan und wurde beendet. Welten werden vor Backups auf die Platte geschrieben, deshalb kostet das selten Daten. Ein Server, der den Stopp-Befehl regelmäßig ignoriert, ist aber einen Blick wert.

Der Worker verliert den LeiterLink zum Abschnitt kopieren

Verbindung zum Leiter beendet, neuer Versuch in 5 Sekunden

Der Worker behält seine laufenden Server und verbindet sich von selbst neu. Kommt er nicht zurück, prüf, ob die API des Leiters vom Worker aus erreichbar ist und ob beide dasselbe Token verwenden. Die Verbindung im Verbund soll innerhalb eines privaten Netzes bleiben.

Die API antwortet nichtLink zum Abschnitt kopieren

GET /api/health braucht kein Token und sagt dir, ob die Cloud selbst läuft. Ein 401 heißt, dass das Token fehlt oder falsch ist, eine leere Antwort heißt, dass du mit der falschen Adresse sprichst. Standardmäßig lauscht die API auf 127.0.0.1:8770, das ist nur vom Server selbst aus erreichbar, und das ist Absicht.

Server aus einem früheren LaufLink zum Abschnitt kopieren

3 Server aus einem früheren Lauf beendet

Die Cloud wurde beendet, ohne herunterzufahren, und hat beim Start verwaiste Prozesse gefunden. Sie werden gestoppt, damit Ports und Welten frei sind. Du musst nichts tun.