Killing Floor server hängt im loading - Kurios!

D

dommi81

New Member
Hallo liebe Gemeinde,

ich bin Admin von 3 Hetzner EX4 servern. Alle 3 sind Identisch, bis auf minimalste kleinigkeiten. (IP/noch keine domain)

Auf jeden der Server wurden Killingfloor Server mittels steamcmd installiert. Alle sind sofort bespielbar außer die eines Servers.

Der KF Server läuft an, der consolen output ist mit den anderen Servern komplett identisch. Das Webinterface ist erreichbar mit allen funktionen. In HLSP Pingt er freudig und lässt sich auch über rcon steuern.

Leider Kommt beim draufjoinen bei jedem der "Verbindung herstellen (F10 Abrechen) killingfloor://IP.IP.IP.IP/Index.rom

Was schon unternommen wurde:
-Alle Libs und pakete nachinstalliert die auf den anderen beiden server auch drauf sind.
-Port gewechselt
-User gewechselt
-Lauffähige Installation von anderen server installiert
-20 neu installiert
-uvm

Wir haben vorhin einen UT2004 server installiert mit der selben engine. Dieser läuft komischerweise.

Alle anderen Gameserver laufen auch ohne macken (hl2/css/cs:go/ut2004/ARMA/DayZ)

Ich weiß nicht mehr weiter und bis auf Neuinstallation vom ganzen Server wurde schon "alles" versucht.
 
Ich selbst habe eigentlich nichts mit Killing Floor am Hut. Mir ist letztens beim Testen aufgefallen, dass der Server eine neuere Version der libgcc_s.so.1 und libstdc++.so.6 benötigt, als Debian ausliefert.

Wenn du z.B. eine CSGO oder CSS-Server über das Updatetool herunterlädst, werden diese mit ausgeliefert. ggf. kann ich dir die beiden Dateien auch irgendwo hochladen. Zur Zeit habe ich selbst keinen Gameserver installiert und müsste auf andere Quellen zurückgreifen.
 
Probiere es doch 'mal mit den Debian Backports bzw. vergleich 'mal die /etc/apt/sources.list und den Output von "dpkg -l" aller Server. Den Output von "dpkg -l" kannst Du vergleichen, wenn Du
Code: 
dpkg -l > ~/dpkg.out
ausführst und diese Datei alle auf einen Server kopierst und dann dort mit
Code: 
diff dpkg.out.erster dpkg.out.zweiter
diff dpkg.out.erster dpkg.out.dritter
diff dpkg.out.zweiter dpkg.out.dritter
vergleichst.
 
Da fangen die Probleme schon an. Wenn man bei Debian die neue Lib haben möchte, muss man auf Testing oder Unstable zurückgreifen. Spätestens dann fangen die Probleme mit den Abhängigkeiten an. Aus dem Grund liefern die Spieleentwickler auch die neueren Libs mit aus. Die Lösung ist zwar nicht gern gesehen, funktioniert aber ohne Eingriff in das System.

Aus dem Grund setzen die Shell-Scripts der unterschiedlichsten Gameserver immer LD_LIBRARY_PATH auf den aktuellen Pfad. Ganz toll wird es dann, wenn die Leute auf die Idee kommen Doppelpunkte im Pfad zu verwenden und statt dem relativen Pfad ein Absoluter Pfad für LD_LIBRARY_PATH verwendet wird.

Wenn ich heute wieder bei meinem Lieblingsprovider bin, werde ich mal die beiden Libs sichern. Die dann einfach in das Verzeichnis system des Gameservers packen und den GS starten.
 
Ich selbst habe eigentlich nichts mit Killing Floor am Hut. Mir ist letztens beim Testen aufgefallen, dass der Server eine neuere Version der libgcc_s.so.1 und libstdc++.so.6 benötigt, als Debian ausliefert.

Wenn du z.B. eine CSGO oder CSS-Server über das Updatetool herunterlädst, werden diese mit ausgeliefert. ggf. kann ich dir die beiden Dateien auch irgendwo hochladen. Zur Zeit habe ich selbst keinen Gameserver installiert und müsste auf andere Quellen zurückgreifen.
Click to expand...

Ein kleiner Hoffnungsschimmer. Beide bzw alle Server wurden mit steamcmd installiert, der eine läuft der andere nicht. Die shared gcc libs sind schon neuere als in den squeeze repos (wg kompilieren).

Werden mal die libs laden und exportieren oder im exe pfad rein kloppen. Mich wunderts nur das ich keine Fehlermeldung bekam wie sonst üblich bei versch. libs.

..stay tuned ;)
 
Okay, die beinen libs habe ich reinkopiert, in der ucc-bin die Path variable absolut gesetzt uvm. Ein LDD zeigt das alle abhängigkeiten der libs aufgelöst werden, auch mit der richtigen Version. Aber der selbe fehler wie vorher.

@DeaD_EyE:
Ich nehme gerne auch mal deine libs, obwohl ich der Überzeugung bin das es daran nicht liegt. Was Steam mit den libs Pfuscht haben wir ja erst kürzlich bei hl2mp gesehen, aber das ist hier warscheinlich nicht der Fall weil ich schon jede 5 mal umgedreht und aus einer laufenden installation etc. habe.

@Fusl:
Deine DPKG methode haben wir schon vor wochen ausprobiert und mit dieser liste alle DEBs nachinstalliert. Also das "verzweifelt" Stadium haben wir schon längst überschritten. Beim Stadium 777 sind wir noch nicht angelangt XD

Ich möchte noch anmerken das wir eine andere Vermutung haben. Die beiden Server auf denen es NICHT läuft haben einen 5.0.0.0 Adressraum, ich jedoch eine 176.9.18.xxx.

Ich glaube auch schon einmal was gelesen zu haben das es bei diesen reservierten Adressraum zu Problemen kommen könnte i.V. mit Serverdiensten. Weiß jemand was darüber?

Die IP ist auch wirklich das einzigste was die Server noch unterscheidet (außer Domain)
 
Last edited by a moderator:
Hey Leute,

sorry das ich dieses Thema nochmals Auspacke aber ich habe schon seit längerem ähnliche Probleme mit Hetzner.

Keinerlei Fehler im Serverlog zu sehen.

Ein tcpdump auf dem Server zeigte, es werden die Queryrequests auf port 7708 beantwortet wenn der Refresh-button des Serverbrowsers betätigt wird, nur auf Port 7707 ist keinerlei Kommunikation zu erkennen. Fehlermeldung nach längerem warten und abbrechen durch F10: noreconnect

IP Bereich: 5.9.XXX.XXX

offene Serverports
Code: 
udp        0      0 0.0.0.0:20560           0.0.0.0:*
udp        0      0 0.0.0.0:7707            0.0.0.0:*
udp        0      0 0.0.0.0:7708            0.0.0.0:*
udp        0      0 0.0.0.0:7717            0.0.0.0:*
udp        0      0 0.0.0.0:7718            0.0.0.0:*
udp        0      0 0.0.0.0:10707           0.0.0.0:*
udp        0      0 0.0.0.0:28852           0.0.0.0:*

Ich war ebenfalls am überlegen ob eine weitere IP das Problem beheben würde, allerdings habe ich keine Garantie das sie aus einem anderen Subnetz sein wird.

Jemand irgendeine Idee dies zu beheben? Ich wäre über jegliche Hilfe dankbar.
 
Das Problem mit dem 5.0.0.0/8 Adressbereich war, dass dieser auch intern von Hamachi verwendet wurde(jetzt 25.0.0.0/8) und dadurch Clients mit installiertem Hamachi den Server nicht erreichen können.

Beim Server selbst sollte es keine Probleme dadurch geben.
 
Hey Jesaja,

danke für die Antwort, leider habe ich keinen Hamatchi Client und/oder Server auf meinem Linux laufen, der das verursachen könnte ;)

Das Problem ist von mehreren Clients aus getestet und mindestens einer (ich) hat defintiv kein Hamatchi oder ähnliches installiert.

Besteht eventuell eine inkompatibilität mit dem KillingFloor Server und der IP-(Range)? Leider habe ich dazu nichts brauchbares gefunden....
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top