Metin2 Syserr lesen: Fehlerlogs richtig deuten

Wenn du einen Metin2-Server betreibst, wirst du früher oder später die metin2 syserr-Dateien lesen müssen. Wenn der Core abstürzt, eine Quest nicht funktioniert oder Spieler melden „ich crashe bei jedem Teleport", versteckt sich die Antwort fast immer in diesen Logzeilen. Das Problem ist, dass die meisten Leute die syserr öffnen, in Panik geraten und wahllos Dateien bearbeiten. Diese Logs werden jedoch nach einer bestimmten Logik geschrieben; sobald du diese Logik begriffen hast, kannst du die Quelle eines Fehlers innerhalb von Minuten lokalisieren.

Syserr, syslog und die anderen Logdateien

Auf der Metin2-Serverseite erzeugt jeder Core- und Datenbankprozess seine eigenen Logdateien. Damit du sie nicht verwechselst, klären wir zuerst, wofür jede gedacht ist:

• syserr — Dein Hauptfokus. C++-Fehler, Quest-Compile-/Laufzeitfehler, fehlende Proto-Einträge und die letzten Warnungen vor einem Crash landen hier.
• syslog — Der normale Ablauf: Spieler-Logins/-Logouts, Kanalstarts, periodische Infomeldungen. Du erkennst wann ein Crash passierte daran, wo die syslog aufhört.
• das Log auf DB-Seite — Die syserr des DB-Cores (auth/db); SQL-Abfragefehler und Probleme beim Speichern von Spielern erscheinen hier.

Jeder Core hat seinen eigenen Ordner (meist channel1/core1, core2 usw.). Um zu wissen, welcher Kanal das Problem hat, musst du in die Datei im richtigen Ordner schauen. Um einen Crash live zu erwischen, ist der klassische Ansatz:

tail -f channel1/core1/syserr
grep -i "error" syserr | tail -n 50

Die Anatomie einer syserr-Zeile

Eine typische Zeile sieht so aus:

SYSERR: Jun 27 21:14:03 :: pcg::Boot: cannot find proto file Data/object_proto

Zerlegen wir sie. Das vorangestellte Tag SYSERR: sagt dir, dass die Zeile ein Fehler ist. Dann folgt Datum und Uhrzeit — vergleiche sie immer mit der syslog und mit der Crash-Zeit der Spieler. Danach kommt der durch :: getrennte Quellen-Marker: meist in der Form Funktionsname: oder Klassenname::Methode. Der letzte Teil ist die eigentliche Meldung: Dinge wie „cannot find", „null pointer", „no such", „syntax error". Ordne es beim Lesen so: wann → wo → was. Sobald du dieses Trio trennst, grenzt du schnell ein, aus welchem System der Fehler kam (Item, Quest, Netzwerk, DB).

Die häufigsten Fehlermuster

Über die Jahre gibt es eine Handvoll Muster, die du in der syserr immer wieder siehst. Hier ein paar mit ihrer wahren Ursache:

• QUEST-Fehler — QUEST ... attempt to index a nil value oder attempt to call a nil value. Das bedeutet, dass du auf eine undefinierte Variable oder Funktion innerhalb einer Quest zugegriffen hast. Es kommt meist von einer falsch geschriebenen pc./npc.-Funktion oder einer gelöschten globalen Variable.
• QUEST-Compile-Fehler — LoadStateUserData ... error oder ein Syntaxfehler in der quest_compile-Ausgabe. Der Lua-Datei fehlt ein end, sie hat einen nicht geschlossenen when-Block oder einen schlecht geschlossenen String.
• Proto / fehlender Eintrag — cannot find item ... oder VID ... mob proto not exist. Es gibt eine Abweichung zwischen dem Item- oder Mob-Proto und der DB; ein neues vnum, das du hinzugefügt hast, fehlt auf einer Seite.
• SQL-Fehler — in der DB-syserr: AsyncSQL ... Unknown column oder Duplicate entry. Die Tabellenstruktur passt nicht zu dem Schema, das der Core erwartet.
• Crash-Signaturen — SEGV, signal 11 oder die abrupt abgeschnittene Zeile. Das ist ein Null-Pointer oder ein Zugriff auf eine beschädigte Datenstruktur.

Den Moment des Crashs einfangen

Fixiere dich bei Crashs nicht auf eine einzelne Zeile. Worauf es ankommt, sind die letzten paar Zeilen direkt vor dem Crash. Was tat der Prozess, bevor er starb? Spawnte er einen Mob, lud er eine Quest oder ließ er einen Spieler einloggen? Sehr oft versteckt sich die Operation, die den Crash auslöste, in der letzten SYSERR-Zeile oder in der Warnung direkt darüber.

In der Praxis mache ich Folgendes: Ich nehme die Crash-Zeit aus der syslog und filtere dann die syserr-Zeilen derselben Minute:

grep "Jun 27 21:14" syserr
tail -n 100 syserr

Wenn der Core wirklich mit SEGV stirbt und die Ursache unklar ist, wurde möglicherweise ein Core-Dump erzeugt. Wenn ulimit -c unlimited gesetzt ist, erscheint eine core.PID-Datei im Crash-Ordner und du kannst mit gdb einen Backtrace erhalten:

gdb ./game core.12345
bt full

Der Backtrace zeigt dir genau, in welcher C++-Funktion der Crash passierte — etwas, das dir die syserr allein nicht sagen kann.

Der Weg zur Grundursache

Wenn du eine Fehlermeldung siehst, folge dieser Reihenfolge, statt panisch Dateien zu bearbeiten:

• Suche die Meldung wörtlich. Nimm die markanten Wörter aus dem SYSERR-Text (vnum, Funktionsname, Tabellenname) und suche sie in deinen Quest-Dateien und der Config mit grep -rn.
• Denk an die letzte Änderung. Hat der Fehler gerade erst begonnen? Dann schau dir an, was du zuletzt hinzugefügt hast (ein neues Item, eine neue Quest, einen neuen Mob). Die syserr sagt meist „das neu hinzugefügte Ding wurde unvollständig definiert".
• Isoliere es. Deaktiviere die verdächtige Quest vorübergehend, starte den Core neu und schau, ob sich die syserr bereinigt.
• Eine Änderung, ein Test. Wenn du fünf Dateien auf einmal bearbeitest, wirst du nie wissen, welche es behoben hat.

Diese Disziplin verwandelt „Reparieren durch Glück" in „Reparieren mit Methode". In der Metin2-Serverwartung ist das die wertvollste Fähigkeit.

Die Logs sauber halten

Auf einem gesunden Server ist die syserr ruhig. Eine syserr, die jeden Tag wächst und voller sich wiederholender Warnungen ist, ist Rauschen, das einen echten Fehler verbirgt. Behebe harmlose, sich wiederholende Warnungen an der Quelle, denn wenn ein echter Crash kommt, willst du ihn nicht unter Tausenden Rauschzeilen verlieren. Archiviere oder rotiere alte Logs regelmäßig (logrotate), damit die Dateien handhabbar bleiben und grep schnell bleibt.

Häufige Fragen

Die syserr ist leer, aber das Spiel crasht, was soll ich tun?

Das bedeutet meist, dass der Prozess abrupt starb, bevor er schreiben konnte (ein harter SEGV). Stelle zuerst sicher, dass du in den richtigen Kanal-/Core-Ordner schaust, aktiviere dann Core-Dumps mit ulimit -c unlimited und nimm einen gdb-Backtrace. Auf Systemebene kann dmesg auch einen Out-of-Memory- oder Segfault-Eintrag zeigen.

Wie finde ich einen QUEST-nil-value-Fehler?

Die Meldung enthält meist den Quest-Namen oder eine Zeilennummer. Öffne diese Quest, schau, welche Variable/Funktion in der angegebenen Zeile aufgerufen wird; höchstwahrscheinlich gibt es einen falsch geschriebenen Funktionsnamen oder eine undefinierte globale Variable. Vergiss nicht, die Quest neu zu kompilieren und den Core neu zu starten.

Dieselbe Fehlerzeile wird hunderte Male pro Sekunde geschrieben?

Das ist ein anhaltender Fehler innerhalb einer Schleife — zum Beispiel ein kaputter Mob, der ständig respawnt, oder eine fehlerhafte Timer-Quest, die bei jedem Tick aufgerufen wird. Deaktiviere zuerst den Auslöser (Mob/Quest), damit das Log nicht anschwillt, und behebe dann in Ruhe die Grundursache.

Syserr zu lesen heißt, das Raten aufzugeben und auf die Beweise zu schauen. Wenn du mit einem kniffligen Crash, einem hängenden Core oder einem Quest-Fehler kämpfst, den du nicht lösen kannst, können wir die Logs gemeinsam durchgehen und zur Quelle zurückverfolgen — nimm Kontakt mit mir auf.