Teil 1: Server-Migration auf Linux (Schritt-für-Schritt-Algorithmus)

Die meisten Entwickler erstellen und testen ihre Spielmodi (Gamemodes) auf lokalen Windows-Computern. Der Betrieb eines Servers im Live-Betrieb (für echte Spieler) erfordert jedoch Stabilität, Sicherheit und hohe Leistung, die nur ein Linux-Betriebssystem (Ubuntu, Debian, CentOS) auf den Kapazitäten eines professionellen Spielhostings bieten kann.

Der Migrationsprozess eines Servers von Windows auf Linux sowie die anschließende Suche nach den Ursachen für Serverabstürze stellen angehende Administratoren oft vor Herausforderungen. In diesem Leitfaden zeigen wir Ihnen, wie Sie einen Server ohne Datenverlust migrieren und eventuelle Code-Crashes lokalisieren.

Wichtige architektonische Unterschiede

Der wesentliche architektonische Unterschied zwischen Windows und Linux, der den Betrieb eines SA:MP/CRMP-Servers beeinträchtigen kann, ist die Unterscheidung zwischen Groß- und Kleinschreibung (Case Sensitivity) bei Dateinamen und Pfaden sowie die Verwendung unterschiedlicher Formate für dynamische Bibliotheken (Plugins).

Schritt 1: Plugins austauschen (.dll zu .so)

Das Linux-Betriebssystem kann nicht mit dynamischen Bibliotheken im Windows-Format .dll arbeiten. Es benötigt stattdessen Shared-Object-Dateien mit der Endung .so.

1. Laden Sie die Linux-Versionen aller von Ihrem Mod verwendeten Plugins herunter (z. B. Crashdetect, MySQL, Streamer, DC_CMD, Pawn.RakNet). Diese finden Sie in der Regel auf den offiziellen GitHub-Seiten der Entwickler.
2. Laden Sie die Dateien mit der Endung .so via SFTP in den Ordner plugins/ auf Ihrem Hosting-Server hoch.
3. Öffnen Sie die Konfigurationsdatei server.cfg im Texteditor Ihres Control Panels und suchen Sie die Zeile plugins. Ersetzen Sie die Dateinamen entsprechend.

Beispiel für Windows: plugins sscanf.dll mysql.dll streamer.dll
Richtige Variante für Linux: plugins sscanf.so mysql.so streamer.so (Einige moderne Versionen von SA:MP erlauben es auch, Plugins ganz ohne Dateiendung anzugeben; das System setzt dann automatisch die richtige Endung ein).

Schritt 2: Korrektur der Groß- und Kleinschreibung (Case Sensitivity)

Während Windows die Pfade Scriptfiles/Users/Player.ini und scriptfiles/users/player.ini als dieselbe Datei behandelt, handelt es sich unter Linux um zwei völlig unterschiedliche Pfade. Wenn Ihr Skript auf einen Ordner in Kleinschreibung verweist, dieser auf der Festplatte jedoch mit einem Großbuchstaben beginnt, wirft der Server einen Fehler aus oder kann die Spielerdaten nicht speichern.

• Ändern Sie die Namen aller wichtigen Ordner (gamemodes, filterscripts, scriptfiles, plugins) konsequent in Kleinschreibung.
• Überprüfen Sie den internen Code des Mods (Pawn): Pfade in Funktionen wie fopen(), fexist() und db_open() müssen exakt mit der tatsächlichen Schreibweise auf dem Hosting-Server übereinstimmen.

Teil 2: Server-Crashes debuggen mit Crashdetect

Wenn der SA:MP-Server zwar startet, aber während des Spielbetriebs plötzlich unerwartet schließt ("abstürzt"), ist das Standard-Log server_log.txt selten aufschlussreich – meist bricht es einfach ab. Um herauszufinden, welche Zeile im Pawn-Skript den kritischen Fehler verursacht hat, müssen Sie das Plugin Crashdetect verwenden.

Schritt 1: Kompilieren des Mods mit Debug-Symbolen

Standardmäßig komprimiert der Pawn-Compiler (pawncc.exe) den Code und entfernt Zeileninformationen aus der fertigen .amx-Datei. Damit Crashdetect den genauen Fehlerort anzeigen kann, muss der Mod mit einem speziellen Flag neu kompiliert werden.

1. Öffnen Sie Ihren Code-Editor (Pawno, Visual Studio Code oder Sublime Text).
2. Fügen Sie in den Compiler-Optionen das Flag -d3 hinzu.
3. Kompilieren Sie Ihren Spielmod-Skript neu. Die Größe der resultierenden .amx-Datei wird sich erhöhen – das ist normal, da die Debug-Symbole darin eingebettet werden. Laden Sie die neue .amx-Datei auf das Hosting hoch.

Wichtig: Die Verwendung des Flags -d3 beeinträchtigt die Serverleistung im Live-Betrieb nicht, ermöglicht es Ihnen jedoch, bei einem Absturz einen detaillierten Call-Stack (Aufrufstapel) zu erhalten.

Schritt 2: Analyse der Crashdetect-Logs

Nach der Installation des Plugins und der Kompilierung mit dem Flag -d3 wird im Falle eines Server-Absturzes ein detaillierter Bericht (Backtrace) in die Log-Datei geschrieben. Hier ist ein Beispiel für einen typischen Fehler:

[14:22:10] [crashdetect] Crash detected while executing mygamemode.amx
[14:22:10] [crashdetect] AMX backtrace:
[14:22:10] [crashdetect] #0 native PlayerPlaySound () from samp-server
[14:22:10] [crashdetect] #1 in public OnPlayerDisconnect (playerid=5, reason=1) at gamemodes/mygamemode.pwn:1432
[14:22:10] [crashdetect] Run time error 4: "Array index out of bounds" (Array size 50, index 55)

So lesen Sie dieses Log:

Häufige Ursachen für Server-Crashes beim Hosting

1. Endlosschleifen (Server Freezing): Wenn eine while- oder for-Schleife falsch konfiguriert ist und keine erreichbare Abbruchbedingung besitzt, blockiert der Server-Thread. Das Hosting registriert eine 100%ige CPU-Auslastung, der Server reagiert nicht mehr auf Netzwerkanfragen ("friert ein") und wird vom Watchdog-Timer des Control Panels zwangsweise neu gestartet.
2. MySQL-Speicherlecks (Memory Leaks): Die häufige Verwendung von Funktionen wie cache_get_row_count() oder rechenintensiven, unoptimierten SQL-Abfragen innerhalb von Schleifen, ohne den zugewiesenen Speicher anschließend freizugeben (wie cache_delete in älteren Plugin-Versionen), verbraucht nach und nach den verfügbaren Arbeitsspeicher (RAM). Wenn das RAM-Limit des Hosting-Containers erschöpft ist, wird der Serverprozess sofort vom Betriebssystem beendet (Out Of Memory / OOM Killer-Fehler).

Tipp: Lassen Sie das Crashdetect-Plugin auch auf Ihrem Live-Produktionsserver immer aktiv. Es verbraucht verschwindend geringe Ressourcen, spart Ihnen jedoch bei der Fehlersuche nach einem neuen Update Stunden an Arbeit.