systemd-Service: Spielserver automatisch starten

Der zuverlässigste Weg, einen Spielserver am Leben zu halten, ist die Verwaltung seines Prozesses über eine systemd-Service-Datei. Prozesse, die mit screen oder nohup im Hintergrund gestartet werden, verschwinden beim Neustart des Servers, und niemand bringt sie nach einem Absturz zurück. systemd hingegen startet Ihren Spielprozess beim Booten automatisch, startet ihn nach einem Absturz neu und macht die gesamte Ausgabe an einem Ort lesbar. In diesem Artikel verwandeln wir einen Spielprozess von Grund auf in einen systemd-Service.

Warum einen systemd-Service verwenden?

Ob Metin2, Minecraft, ein C++-Spielkern oder Ihr eigenes Server-Binary: Es sind allesamt langlaufende Hintergrundprozesse. Sie direkt aus einem Terminal zu starten führt zu diesen Problemen:

• Der Prozess stirbt, sobald die SSH-Sitzung geschlossen wird.
• Das Spiel kommt nach einem Neustart nicht automatisch zurück.
• Ein Absturz erfordert einen manuellen Eingriff.
• Logs sind verstreut, was die Nachverfolgung erschwert.

systemd löst all das. Es ist das Standard-Init-System moderner Linux-Distributionen (Debian, Ubuntu, AlmaLinux, Rocky), Sie müssen also nichts Zusätzliches installieren.

Einen eigenen Benutzer für den Service anlegen

Aus Sicherheitsgründen sollten Sie den Spielprozess nicht als root ausführen. Legen Sie einen dedizierten Systembenutzer ohne Shell an:

sudo useradd --system --create-home --shell /usr/sbin/nologin gameserver
sudo mkdir -p /opt/game
sudo chown -R gameserver:gameserver /opt/game

Legen Sie Ihre Spieldateien unter /opt/game ab und prüfen Sie die Rechte des ausführbaren Binarys: chmod +x /opt/game/start. Dieser Benutzer führt nur das Spiel aus und kann sich nicht am System anmelden, was die Auswirkungen einer möglichen Sicherheitslücke begrenzt.

Die systemd-Service-Datei schreiben

Service-Definitionen liegen in Dateien mit der Endung .service unter /etc/systemd/system/. Erstellen Sie /etc/systemd/system/gameserver.service:

[Unit]
Description=Spielserver
After=network.target

[Service]
Type=simple
User=gameserver
Group=gameserver
WorkingDirectory=/opt/game
ExecStart=/opt/game/start
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Bedeutung der Abschnitte:

• [Unit] — After=network.target stellt sicher, dass der Service nicht startet, bevor das Netzwerk bereit ist.
• Type=simple — Die richtige Wahl, wenn der Prozess im Vordergrund läuft (das tun die meisten Spielserver). Wenn sich der Prozess selbst daemonisiert, verwenden Sie Type=forking.
• WorkingDirectory — Manche Spielkerne suchen Konfigurationsdateien relativ zum Arbeitsverzeichnis; setzen Sie dies immer.
• ExecStart — Der vollständige auszuführende Befehl. Verwenden Sie immer einen absoluten Pfad; systemd setzt keinen PATH voraus.
• Restart=on-failure — Startet den Prozess neu, wenn er mit einem von null verschiedenen Code beendet wird. RestartSec=5 wartet 5 Sekunden vor dem Neustart.
• LimitNOFILE — Erhöht das Limit offener Dateien/Sockets für viele Spielerverbindungen.

Den Service aktivieren und starten

Nachdem Sie die Datei gespeichert haben, lassen Sie systemd die neue Definition einlesen, aktivieren den Service für den Start beim Booten und führen ihn aus:

sudo systemctl daemon-reload
sudo systemctl enable gameserver
sudo systemctl start gameserver

Prüfen Sie den Status:

sudo systemctl status gameserver

Wenn Sie in der Ausgabe active (running) sehen, läuft der Service. Der Befehl enable hängt den Service in multi-user.target ein, sodass das Spiel bei jedem Serverstart zurückkommt. Um beides in einem Befehl zu erledigen, verwenden Sie systemctl enable --now gameserver.

Logs mit journalctl verfolgen

systemd sammelt die Standardausgabe und Fehlerausgabe des Prozesses in journald, sodass Sie keine separate Logdatei verwalten müssen:

# Aktuelle Logs anzeigen
sudo journalctl -u gameserver

# Live verfolgen (wie tail)
sudo journalctl -u gameserver -f

# Nur die Logs von heute
sudo journalctl -u gameserver --since today

Wenn Ihr Spielkern eigene Logdateien schreibt, bleiben diese an Ort und Stelle; journald erfasst nur das, was auf die Konsole ausgegeben wird. Um zu verhindern, dass die Festplatte volläuft, sollten Sie ein Limit wie SystemMaxUse=500M in /etc/systemd/journald.conf setzen.

Sauberes Herunterfahren und häufige Fehler

Viele Spielserver brauchen beim Stoppen ein sanftes Herunterfahren, um Spielerdaten zu speichern. Standardmäßig sendet systemd SIGTERM; idealerweise fängt Ihr Prozess dies ab und beendet sich sauber. Passen Sie das Zeitfenster bei Bedarf an:

[Service]
TimeoutStopSec=30
KillSignal=SIGINT

Die häufigsten Probleme: ein falscher Pfad (ExecStart muss absolut sein), ein Rechtefehler (das Binary muss dem Benutzer gameserver gehören und ausführbar sein) und ein falscher Type (Type=simple für einen sich selbst forkenden Prozess lässt den Service ständig „neu starten" erscheinen). Vergessen Sie nicht, nach jeder Änderung sudo systemctl daemon-reload auszuführen.

Häufig gestellte Fragen

Was muss ich nach dem Bearbeiten des Services tun?

Jedes Mal, wenn Sie die .service-Datei ändern, führen Sie zuerst sudo systemctl daemon-reload und dann sudo systemctl restart gameserver aus. Andernfalls verwendet systemd weiterhin die alte Definition.

Kann ich mehrere Spielinstanzen betreiben?

Ja. Schreiben Sie dieselbe Vorlage als Template-Unit mit dem Namen gameserver@.service und starten Sie Instanzen wie systemctl start gameserver@1, gameserver@2. Jede Instanz erhält über die Variable %i ihren eigenen Port oder ihre eigene Konfiguration.

Warum startet der Prozess ständig neu?

Meist bedeutet das, dass das Binary sofort beendet wird. Lesen Sie die echte Fehlermeldung mit journalctl -u gameserver -f; oft liegt es an einer fehlenden Konfigurationsdatei, einem nicht verfügbaren Port oder einem falschen Arbeitsverzeichnis.

Möchten Sie Ihre Serverinfrastruktur härten? Wenn Sie Hilfe bei der Einrichtung eines Spielservers, bei systemd-Services oder der Linux-Administration brauchen, nehmen Sie Kontakt mit mir auf.