Reading Metin2 Syserr: Interpreting Error Logs

If you run a Metin2 server, sooner or later you will have to read metin2 syserr files. When the core crashes, a quest refuses to work, or players report "I drop every time I teleport", the answer is almost always hidden in these log lines. The problem is that most people open syserr, panic, and start editing files at random. But these logs are written with a specific logic; once you grasp that logic, you can pinpoint the source of an error within minutes.

Syserr, syslog and the other log files

On the Metin2 server side, every core and database process produces its own log files. To avoid mixing them up, let's first clarify what each one is for:

• syserr — Your main focus. C++ errors, quest compile/runtime errors, missing proto entries and the last warnings before a crash all land here.
• syslog — The normal flow: player logins/logouts, channel startups, periodic info messages. You can tell when a crash happened from where syslog stops.
• the db-side log — The syserr of the DB core (auth/db); SQL query errors and player-saving problems show up here.

Each core has its own folder (usually channel1/core1, core2, etc.). To know which channel has the issue, you must look at the file in the right folder. To catch a crash live, the classic approach is:

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

The anatomy of a syserr line

A typical line looks like this:

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

Let's break it down. The leading SYSERR: tag tells you the line is an error. Then comes the date and time — always compare it with syslog and with the players' crash time. Next is the source marker separated by ::: usually in the form FunctionName: or ClassName::Method. The final part is the actual message: things like "cannot find", "null pointer", "no such", "syntax error". When reading, order it: when → where → what. Once you separate that triad, you quickly narrow down which system the error came from (item, quest, network, DB).

The most common error patterns

Over the years there are a handful of patterns you see again and again in syserr. Let's list a few and their real cause:

• QUEST errors — QUEST ... attempt to index a nil value or attempt to call a nil value. This means you accessed an undefined variable or function inside a quest. It usually comes from a misspelled pc./npc. function or a deleted global.
• QUEST compile error — LoadStateUserData ... error or a syntax error in the quest_compile output. The Lua file has a missing end, an unclosed when block, or a badly closed string.
• Proto / missing entry — cannot find item ... or VID ... mob proto not exist. There is a mismatch between the item or mob proto and the DB; a new vnum you added is missing on one side.
• SQL errors — in the DB syserr: AsyncSQL ... Unknown column or Duplicate entry. The table structure does not match the schema the core expects.
• Crash signatures — SEGV, signal 11, or the line being cut off abruptly. This is a null pointer or access to a corrupted data structure.

Catching the moment of the crash

With crashes, don't fixate on a single line. What matters is the last few lines right before the crash. What was the process doing before it died? Was it spawning a mob, loading a quest, or letting a player log in? Very often the operation that triggered the crash is hidden in the last SYSERR line or in the warning just above it.

In practice, here is what I do: take the crash time from syslog, then filter the syserr lines from the same minute:

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

If the core really dies with SEGV and the cause is unclear, a core dump may have been produced. If ulimit -c unlimited is set, a core.PID file appears in the crash folder and you can get a backtrace with gdb:

gdb ./game core.12345
bt full

The backtrace shows you exactly which C++ function the crash happened in — something syserr alone cannot tell you.

The path to the root cause

When you see an error message, instead of editing files in a panic, follow this order:

• Search the message verbatim. Take the distinctive words from the SYSERR text (vnum, function name, table name) and grep for them in your quest files and config with grep -rn.
• Think about the last change. Did the error just start? Then look at whatever you added last (a new item, a new quest, a new mob). Syserr usually says "the newly added thing was defined incompletely".
• Isolate it. Temporarily disable the suspect quest, restart the core, and see whether the syserr clears up.
• One change, one test. If you edit five files at once, you'll never know which one fixed it.

This discipline turns "fixing by luck" into "fixing by method". In Metin2 server maintenance, that is the most valuable skill.

Keeping the logs clean

On a healthy server, syserr is quiet. A syserr that grows every day and is full of repeating warnings is noise that hides a real error. Fix harmless repeating warnings at their source, because when a real crash comes you don't want to lose it among thousands of noise lines. Archive or rotate old logs regularly (logrotate) so the files stay manageable and grep stays fast.

Frequently Asked Questions

Syserr is empty but the game crashes, what should I do?

This usually means the process died abruptly before it had a chance to write (a hard SEGV). First make sure you're looking at the right channel/core folder, then enable core dumps with ulimit -c unlimited and take a gdb backtrace. At the system level, dmesg can also show an out-of-memory or segfault record.

How do I find a QUEST nil value error?

The message usually contains the quest name or a line number. Open that quest, look at which variable/function is called on the given line; most likely there is a misspelled function name or an undefined global. Don't forget to recompile the quest and restart the core.

The same error line is written hundreds of times per second?

That's a persistent error inside a loop — for example a broken mob that keeps respawning, or a faulty timer quest called on every tick. First disable the trigger (mob/quest) so the log stops swelling, then calmly fix the root cause.

Reading syserr means giving up guessing and looking at evidence. If you're dealing with a tricky crash, a stuck core or a quest error you can't solve, we can go through the logs together and trace it to its source — get in touch with me.