Lire le Syserr Metin2 : interpréter les logs d'erreur

Si tu gères un serveur Metin2, tôt ou tard tu devras lire les fichiers metin2 syserr. Quand le core plante, qu'une quête refuse de fonctionner ou que des joueurs signalent « je crash à chaque téléportation », la réponse est presque toujours cachée dans ces lignes de log. Le problème, c'est que la plupart des gens ouvrent le syserr, paniquent et se mettent à modifier des fichiers au hasard. Or ces logs sont écrits selon une logique précise ; une fois cette logique comprise, tu peux localiser la source d'une erreur en quelques minutes.

Syserr, syslog et les autres fichiers de log

Côté serveur Metin2, chaque core et chaque processus de base de données produit ses propres fichiers de log. Pour ne pas les confondre, clarifions d'abord à quoi sert chacun :

• syserr — Ton point central. Les erreurs C++, les erreurs de compilation/exécution des quêtes, les entrées proto manquantes et les derniers avertissements avant un crash atterrissent ici.
• syslog — Le flux normal : connexions/déconnexions des joueurs, démarrages de canaux, messages d'information périodiques. Tu sais quand un crash s'est produit là où le syslog s'arrête.
• le log côté db — Le syserr du core DB (auth/db) ; les erreurs de requêtes SQL et les problèmes d'enregistrement des joueurs apparaissent ici.

Chaque core a son propre dossier (généralement channel1/core1, core2, etc.). Pour savoir quel canal pose problème, tu dois regarder le fichier dans le bon dossier. Pour capter un crash en direct, l'approche classique est :

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

L'anatomie d'une ligne de syserr

Une ligne typique ressemble à ceci :

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

Décomposons-la. La balise initiale SYSERR: indique que la ligne est une erreur. Vient ensuite la date et l'heure — compare-les toujours avec le syslog et avec l'heure de crash des joueurs. Puis vient le marqueur de source séparé par :: : généralement sous la forme NomFonction: ou NomClasse::Méthode. La dernière partie est le message réel : « cannot find », « null pointer », « no such », « syntax error ». En lisant, ordonne ainsi : quand → où → quoi. Une fois ce triptyque séparé, tu restreins vite le système d'où vient l'erreur (item, quête, réseau, DB).

Les schémas d'erreur les plus fréquents

Au fil des années, il y a une poignée de schémas que tu revois sans cesse dans le syserr. En voici quelques-uns avec leur cause réelle :

• Erreurs QUEST — QUEST ... attempt to index a nil value ou attempt to call a nil value. Cela signifie que tu as accédé à une variable ou une fonction non définie dans une quête. Cela vient souvent d'une fonction pc./npc. mal orthographiée ou d'une variable globale supprimée.
• Erreur de compilation QUEST — LoadStateUserData ... error ou une erreur de syntaxe dans la sortie de quest_compile. Le fichier Lua a un end manquant, un bloc when non fermé ou une chaîne mal fermée.
• Proto / entrée manquante — cannot find item ... ou VID ... mob proto not exist. Il y a une incohérence entre le proto d'item ou de mob et la DB ; un nouveau vnum ajouté manque d'un côté.
• Erreurs SQL — dans le syserr de la DB : AsyncSQL ... Unknown column ou Duplicate entry. La structure de la table ne correspond pas au schéma attendu par le core.
• Signatures de crash — SEGV, signal 11, ou la ligne coupée brutalement. C'est un null pointer ou un accès à une structure de données corrompue.

Capter l'instant du crash

Pour les crashs, ne te fixe pas sur une seule ligne. Ce qui compte, ce sont les quelques lignes juste avant le crash. Que faisait le processus avant de mourir ? Faisait-il apparaître un mob, chargeait-il une quête, laissait-il un joueur se connecter ? Très souvent, l'opération qui a déclenché le crash est cachée dans la dernière ligne SYSERR ou dans l'avertissement juste au-dessus.

En pratique, voici ce que je fais : je prends l'heure du crash dans le syslog, puis je filtre les lignes du syserr de la même minute :

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

Si le core meurt vraiment avec SEGV et que la cause est floue, un core dump a peut-être été produit. Si ulimit -c unlimited est activé, un fichier core.PID apparaît dans le dossier du crash et tu peux obtenir une backtrace avec gdb :

gdb ./game core.12345
bt full

La backtrace te montre exactement dans quelle fonction C++ le crash s'est produit — ce que le syserr seul ne peut pas te dire.

Le chemin vers la cause racine

Quand tu vois un message d'erreur, au lieu de modifier des fichiers dans la panique, suis cet ordre :

• Cherche le message tel quel. Prends les mots distinctifs du texte SYSERR (vnum, nom de fonction, nom de table) et recherche-les dans tes fichiers de quête et ta config avec grep -rn.
• Pense au dernier changement. L'erreur vient-elle d'apparaître ? Alors regarde ce que tu as ajouté en dernier (nouvel item, nouvelle quête, nouveau mob). Le syserr dit souvent « la chose ajoutée a été définie de façon incomplète ».
• Isole-la. Désactive temporairement la quête suspecte, redémarre le core et vois si le syserr se nettoie.
• Un changement, un test. Si tu modifies cinq fichiers à la fois, tu ne sauras jamais lequel a corrigé.

Cette discipline transforme la « correction par chance » en « correction par méthode ». Dans la maintenance d'un serveur Metin2, c'est la compétence la plus précieuse.

Garder les logs propres

Sur un serveur sain, le syserr est silencieux. Un syserr qui grossit chaque jour et déborde d'avertissements répétés est du bruit qui cache une vraie erreur. Corrige à la source les avertissements répétés mais inoffensifs, car le jour où un vrai crash arrive, tu ne veux pas le perdre parmi des milliers de lignes de bruit. Archive ou fais tourner les anciens logs régulièrement (logrotate), pour que les fichiers restent gérables et que grep reste rapide.

Questions fréquentes

Le syserr est vide mais le jeu plante, que faire ?

Cela signifie généralement que le processus est mort brutalement avant d'avoir pu écrire (un SEGV brutal). Assure-toi d'abord de regarder le bon dossier de canal/core, puis active les core dumps avec ulimit -c unlimited et prends une backtrace gdb. Au niveau système, dmesg peut aussi montrer un enregistrement out-of-memory ou segfault.

Comment trouver une erreur QUEST nil value ?

Le message contient généralement le nom de la quête ou un numéro de ligne. Ouvre cette quête, regarde quelle variable/fonction est appelée à la ligne indiquée ; il y a très probablement un nom de fonction mal orthographié ou une variable globale non définie. N'oublie pas de recompiler la quête et de redémarrer le core.

La même ligne d'erreur est écrite des centaines de fois par seconde ?

C'est une erreur persistante dans une boucle — par exemple un mob cassé qui réapparaît en boucle, ou une quête timer défaillante appelée à chaque tick. Désactive d'abord le déclencheur (mob/quête) pour que le log cesse de gonfler, puis corrige calmement la cause racine.

Lire le syserr, c'est arrêter de deviner et regarder les preuves. Si tu fais face à un crash délicat, un core bloqué ou une erreur de quête que tu n'arrives pas à résoudre, on peut parcourir les logs ensemble et remonter à la source — contacte-moi.