ubuntuusers.de

Hallo Forum.

Ich habe seit kurzem einen vServer bei Strato (ubuntu 18.04 server). Da habe ich einen Teamspeak-Server eingerichtet und über steamcmd srcds. Teamspeak ließ sich leicht als Service einrichten, srcds aber nicht - bzw. angeblich läuft es, der Gameserver ist aber nicht erreichbar.

Hier habe ich eine Anleitung gefunden, ich denke der Knackpunkt ist "screen".

http://www.srcds.com/db/engine.php?&id=1098643920

Mit dieser Variante muss ich mich aber auch erstmal einloggen zum Starten des Prozesses.

Aber nochmal kurz zu meinem Versuch, vielleicht kann mir jemand Tipps geben.

Die css.service sieht so aus:

[Unit]
Description=CS:S Server

[Service]
Type=simple
User=steam
ExecStart=/home/steam/.steam/steamcmd/css/srcds_run -game cstrike -map de_dust2 -maxplayers 24 -secure

[Install]
#WantedBy=multi-user.target
WantedBy=network-online.target

Und hier der Status des Services. Da ich x64 verwende, habe ich die Fehlermeldung ignoriert. Wenn ich das Spiel im user-context starte, läuft es ja auch.

Was mache ich falsch?

ImmerAufDieKleinen schrieb:

Ich habe seit kurzem einen vServer bei Strato (ubuntu 18.04 server).

Was ist denn mit Strato, bieten die keinen Support mehr für zahlende Kunden? Nur aus Interesse. Und wie immer, Was bedeutet "Haftung" als Server-Betreiber?

Es ist keine gute Idee den Server mit root-Rechten laufen zu lassen. Könnte auch dein Problem sein: → systemd/User Units

RamSpeicher schrieb:

ImmerAufDieKleinen schrieb:

Ich habe seit kurzem einen vServer bei Strato (ubuntu 18.04 server).

Was ist denn mit Strato, bieten die keinen Support mehr für zahlende Kunden? Nur aus Interesse. Und wie immer, Was bedeutet "Haftung" als Server-Betreiber?

Nicht die Antwort die ich erwartet hätte, aber trotzdem danke. Web- und Mail-Dienste habe ich woanders liegen, das ist mir auf meiner Kiste etwas zu heikel, daher werden nur Gameserver installiert.

ChickenLipsRfun2eat schrieb:

Es ist keine gute Idee den Server mit root-Rechten laufen zu lassen. Könnte auch dein Problem sein: → systemd/User Units

Guter Hinweis, dachte allerdings dass das mit der User-Angabe in der .service schon erledigt wäre. Steam meldet auch wenn ich den Prozess im root-context starte, so wie oben kommt die Meldung nicht.

Es ist zwar korrekt erstmal auf die Grundlagen einzugehen, aber warum genau startet jetzt srcds keinen erreichbaren Gameserver?

ImmerAufDieKleinen schrieb:

Guter Hinweis, dachte allerdings dass das mit der User-Angabe in der .service schon erledigt wäre…

Ja, die habe ich eben übersehen, sorry ☺

Es ist zwar korrekt erstmal auf die Grundlagen einzugehen, aber warum genau startet jetzt srcds keinen erreichbaren Gameserver?

Gibt es Einträge im log? journalctl -b -xep 0..4 wäre meine erste Anlaufstelle. Ebenfalls interessant könnte die firewall sein: iptables -L und ip6tables -L, falls du beides bedienst.

Ggf. könntest du auch mal den debug-Modus anwerfen: Command_Line_Options.

Wenn die Kiste dann läuft, können wir uns dein Screen-Script ansehen.

ChickenLipsRfun2eat schrieb:

Gibt es Einträge im log? journalctl -b -xep 0..4 wäre meine erste Anlaufstelle. Ebenfalls interessant könnte die firewall sein: iptables -L und ip6tables -L, falls du beides bedienst.

Gibt hier leider keine Infos (es sind Meldungen, aber die passen zeitlich nicht und die kommen von meinen bekannten Fehlversuchen).

Wenn die Kiste dann läuft, können wir uns dein Screen-Script ansehen.

Ich habe jetzt das screen-script getestet (screen ist auf dem Server installiert), es funktioniert, der Server taucht sofort in der öffentlichen Serverliste auf und ich kann connecten.

Meine Idee war jetzt, dass ich in der css.service einfach den Starteintrag auf die server.sh umbiege. Wenn ich jetzt den service starte, kommt auch keine Fehlermeldung, aber es passiert sonst leider nichts und der Gameserver ist auch nicht erreichbar.

● css.service - CS:S Server
   Loaded: loaded (/etc/systemd/system/css.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Thu 2020-02-20 18:30:16 CET; 3s ago
  Process: 618 ExecStart=/home/steam/.steam/steamcmd/css/css-server.sh (code=exited, status=0/SUCCESS)
 Main PID: 618 (code=exited, status=0/SUCCESS)

Sieht so aus als wenn es ausgeführt aber auch sofort beendet wird. ☹

Wenn das durchläuft und normal beendet, dann tut das die Unit auch. Sobald du einen Screen "detachest", kehrt der Prozess zurück und ist beendet. Ich habe die Abfragerei damals über ein Socket gelöst ( screen -S socketname ), hatte mir aber auch ein mühevoll zusammengeknüppeltes Python-Tool erstellt, um alles zu verwalten. War aber vor systemd und kein CS, sondern Neverwinter Nights 😉

Du kannst aber die systemd-unit ja nutzen und entsprechende Einträge für start, restart und stop hinterlegen → systemd/Service Units

Screen wird detached gestartet, forkt also in den Hintergrund. Du hast damit zwei Möglichkeiten:

• Du rufst weiterhin das Skript auf, aber musst dafür sorgen, dass es sich nicht beendet, solange screen läuft - das kannst du mit wait erreichen:

1
2
3
4
5

#!/bin/sh
echo "Starting Cs:Source Server"
sleep 1
screen -A -m -d -S css-server ./srcds_run -console -game cstrike +map de_dust +maxplayers 16 -autoupdate
wait

• Du startest den Screen-Befehl ohne Umweg über das Bash-Skript (das tut ja nichts relevantes) und sagst systemd, dass der ausgeführte Prozess forken wird:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

[Unit]
Description=CS:S Server
After=network-online.target

[Service]
Type=forking
User=steam
WorkingDirectory=/home/steam/
ExecStart=/usr/bin/screen -A -m -d -S css-server /home/steam/.steam/steamcmd/css/srcds_run -console -game cstrike +map de_dust +maxplayers 16 -autoupdate

[Install]
WantedBy=multi-user.target

Oh! Das geht! Danke! 😀

Edit fragt sich grad wie man sich hier bedankt...