hi.

ich hab ein Problem. und zwar, wenn ich ganz normal den Server starte mit Webadmin und mich dann einlogge und ihn in irgendeiner Form benutze, sprich ich klicke auf Links oder gebe etwas in die Konsole des Webadmins ein, dann sehe ich in der SSH Konsole, die ich anfangs parallel laufen lasse wie der Log förmlich explodiert mit der Warnung "Socket Error" oder "Error occured while trying to bind socket" oder dergleichen.
Wenn ich nichts im Webadmin unternehme, passiert das nicht, spielen kann ich auf dem Server normal.

2 Sachen die mir auffallen: Ich benutze die ucc-bin-linux-amd64 bin-datei und obwohl ich den Patch wie im Tutorial hier auf beide Server gemacht habe, wird mir im Webadmin, in der Konsole und in der Serverinfo angezeigt, dass ich die Version 3339 hätte was ja nicht wahr ist.

außerdem lief der Server über meine Konsole und ich habe auf dem Root noch keinen Apache oder ähnlichen Webserver installiert weil ich das nicht brauche.

Ich habe Suse 10 64 Bit mit einem AMD Sempron 64, 1 gik ram. Der Root ist von hetzner.

bitte um hilfe!

Also ich habe das gleiche Problem.

Ich benutze auch "ucc-bin-linux-amd64"

MFG
Datafreak

Hi,
sind die Rechte richtig vergeben?
Lass nochma das Oatch 3369 komplett drüberlaufen. Danach die Schreibrechte beachten / ausführrechte etc.
Hast du vielleicht einen Tippfehler beim entpacken gemacht?
Du musst beim Entpacken ALLE Dateien überschreiben, die du entpacken willst.
Was steht in der Logdatei für ne Version? 3369 oder 3339?
Es kann sien, dass ne Datei defekt ist oder so. Daher kommen diese vielen Fehler. Gerade, weil es mit dem Patch nicht richtig gefunzt hat, denke ich, dass irgendwas an den Files ist.
teste den Server mal, ob er, wenn er voll ist immer noch stabil läuft. Switche in verschieden Spielmodies etc.
Dann würde ich dir Linux Debian Sarge anstatt Suse Linux als Serversoftware empfehlen. Braucht nämlich weniger Hardwareresourcen und ist einfach besser .

cool.. kommt zwar 6 monate zu spät

aber ist debian anstatt suse denn so ausschlaggebend?

Debian ist einfach die geeignetste Distribution dafür. Sie hat eine weit aus größere Paketsammlung wie Suse.
Aber das muss jeder für sich selbst entscheiden.

Bullshit, welche Begründung hast du dass Suse schlechter ist als Debian?

Edit: Hast du Benchmarks zum Verbrauch der Hardware Ressourcen?

MadMauros hat geschrieben:Sie hat eine weit aus größere Paketsammlung wie Suse.

Reicht das?

Nächstes mal vielleicht zuerst den Post GENAU durchlesen und erst dann "scheisse" von sich geben (das "scheisse" bezieht sich auf dein "Bullshit". Man kann das auch höflicher sagen!)

€:
Benchmarks hab ich leider keine, aber dann geh mal in diverse andere Linuxforen und frag da einfach mal die Cracks. Jeder wird die Debian vorschlagen, weil man es ganz einfach so von anfang an minimal konfigurieren kann. Suse ist da anders. Da wird gleich ne standardeinstellung wie bei Windows installiert
Aber das ist nur einer der Gründe.

Was war denn hier des Rätsels Lösung? Wir lassen ebenfalls nen UT2k4-Server laufen, kaum arbeitet man kurz im Webinterface, endet die Konsole in besagter "Socket Error"-Fehlermeldung. Auch bei uns läuft der Server auf nem AMD64, OS ist Ubuntu. Patchlevel ist natürlich die 3369 mit AMD64-Linux-Patch und allen wichtigen Bonuspacks. Der Server lässt sich wunderbar stabil spielen, ausschließlich das Webinterface löst den Absturz aus.

edit: Die Sache mit fehlerhaften Files schließe ich aus, weil wir den Server mittlerweile mehrfach aufgesetzt haben, die aktuellen Archive liefen auf unserem alten Server einwandfrei. Rechte sind auch korrekt vergeben.

hello,

also nach dem ich das jetzt 10 oder 15 mal durchgelesen habe bin ich auf die Idee gekommen dass ihr mit Terminal/Konsole keine SSH/Telnet-Verbindung meint sondern vielleicht ein emuliertes Terminal übers WEB und hier scheint es anscheinend mit der Zeit einen Timeout zu geben. Kann es sein dass die Bash in diesem "Webterminal" irgendwie über ne Socketdatei kommuniziert? Naja egal, versucht einfach mal von eurem lokalen Rechner auf einem Xtrem/Konsole/aterm/wterm mittels "ssh -luser 1.2.3.4" eine Verbindung mit eurem Server herzustellen.

@MadMauros:

1.) Mach mir doch mal eine Liste von Paketen die du unter Debian (nehmen wir mal testing weil da mehr drinnen sein sollte) zur Verfügung hast und unter einer aktuellen Suserelease nicht. Ich trau mir mal behaupten dass die meisten kleine Spiele/Anwendungen für X sind bzw. Tools die auch bei Debian weniger als 100 Anwender haben. Wenn du nur ein einziges verwendest dass es unter SUSE nicht gibt fühl ich mich geschlagen! ok?

2.) Welche Cracks denn? Ich glaub kaum dass jemand der sich wirklich mit der Materie auskennt dir sagen wird dass Suse langsamer ist als Debian. Ausserdem ist Debian genauso aufgeblasen wie SUSE, vergleich doch mal die größe der beiden Basisinstallationen. Bei Suse sind ca. 500MB (afaik) und bei debian etwas über 300MB. Das heist debian ist fast doppelt so schnell? Wie ist das ganze mit Archlinux wo eine Grundinstallation ungefähr 120 hat? Ist das dann 4 mal so schnell wie Suse?

Irgendwie ist das alles so verwirrend, hä?

EDIT: Ich verwende kein SUSE weil ich grafische Konfigtools nicht mag und weil mir das verwirrspiel mit den Konfigs zu kompliziert ist.

Meine Rechner:
Heimserver: Sarge
Desktop: Kubuntu 5.10 mit Kernel 2.6.16.9 und KDE 3.5.2
Notebook: etch mit 2.6.17 aus unstable, kde 3.5.3 und ein paar paketen aus unstable/experimental
Testrechner: sid/Arch/FBSD usw. je nach dem ...

Dyno-Mize hat geschrieben:hello,

also nach dem ich das jetzt 10 oder 15 mal durchgelesen habe bin ich auf die Idee gekommen dass ihr mit Terminal/Konsole keine SSH/Telnet-Verbindung meint sondern vielleicht ein emuliertes Terminal übers WEB und hier scheint es anscheinend mit der Zeit einen Timeout zu geben. Kann es sein dass die Bash in diesem "Webterminal" irgendwie über ne Socketdatei kommuniziert? Naja egal, versucht einfach mal von eurem lokalen Rechner auf einem Xtrem/Konsole/aterm/wterm mittels "ssh -luser 1.2.3.4" eine Verbindung mit eurem Server herzustellen.

Muss ich dich enttäuschen. Ich arbeite Zuhause auch nur auf Linux/FreeBSD und dementsprechend meine ich auch eine echte Konsole. Das Problem ist ja auch nicht, dass die Konsole explodiert (wenn man mal davon absieht, dass das Log dabei auch explodiert), wenn ich das nicht sehen will, beende ich halt die SSH-Verbindung. Der Server läuft weiter, alles wunderbar, und sobald ich den zweiten Map-Change bzw Map-Restart per Webinterface mache, kommt die Close-Socket-Geschichte wie oben beschrieben

Hast du einen Webserver auf dem selben Port laufen?

Kannst du die Ausgabe im Log mal posten?

Apache läuft auf Port 80, das Webinterface auf 7771. Das war allerdings auch mein erster Ansatz, weil er vor dem Crash meistens beim Start des Webinterfaces nen Bind error rausschmeißt (im geloggten Fall natürlich nicht, das Resultat war aber das gleiche). Komischerweise beim ersten Start nicht und das, obwohl das OS nicht restartet wird. Wir haben für das Webinterface schon diverse Ports durchrotiert und sichergestellt, dass die auch wirklich frei sind, das Problem ist aber mit allen getesteten Ports reproduzierbar gewesen.

Code: Alles auswählen

Log: Server switch level: DOM-Outrigger?game=XGame.xDoubleDom?timelimit=20?goalscore=0?FriendlyFireScale=0,WeaponStay=True?mut  ator=XWeapons.MutNoSuperWeapon,UTCompv16a.mututcomp?
DoubleDamage=True?GrenadesOnSpawn=4?TimedOverTimeLength=0?MaxPlayers=8
Log: Browse: DOM-Outrigger?Name=Player?Class=Engine.Pawn?Character=Jakob?team=255?xGame=xGame.xDoubleDom?mutator=  XWeapons.MutNoSuperWeapon,UTCompv16a.mututcomp?game=XGame.xDouble
Dom?timelimit=20?goalscore=0?FriendlyFireScale=0,WeaponStay=True?DoubleDamage=True?GrenadesOnSpawn=4  ?TimedOverTimeLength=0?MaxPlayers=8
NetComeGo: Close TcpipConnection 84.58.146.244:9253 Fri Aug  4 21:41:05 2006
ScriptLog: -KM-Igno logged out.
NetComeGo: Close TcpipConnection 193.135.144.178:3684 Fri Aug  4 21:41:05 2006
Exit: Socket shut down
Log: (Karma): Level Karma Terminated.
Log: ProcMesh 526 shared verts.
Log: ProcMesh 21 shared verts.
Log: xProcMesh numRigidVerts=104
Log: ProcMesh 21 shared verts.
Log: xProcMesh numRigidVerts=104
Log: ProcMesh 21 shared verts.
Log: xProcMesh numRigidVerts=104
Log: ProcMesh 21 shared verts.
Log: xProcMesh numRigidVerts=104
Log: Collecting garbage
Log: Purging garbage
Log: Garbage: objects: 51937->48043; refs: 652416
Log: Game class is 'xDoubleDom'
Log: Bringing Level DOM-Outrigger.myLevel up for play (25) appSeconds: 352.538206...
ScriptLog: Mutators XWeapons.MutNoSuperWeapon,UTCompv16a.mututcomp
ScriptLog: GameInfo::InitGame : bEnableStatLogging False
ScriptLog: UdpServerQuery(crt): Port 7787 successfully bound.
Log: Resolving master0.gamespy.com...
ScriptLog: MasterServerUplink: MasterServerGameStats not found - stats uploading disabled.
Log: Defaulting to false
Log: Defaulting to false
Log: Resolving ut2004master2.epicgames.com...
WebAdmin: Loading Available Maps
WebAdmin: Loading Game Types
WebAdmin: xWebAdmin.UTServerAdmin Initialized on port 7771
ScriptLog: 
ScriptLog: =================================================================
ScriptLog:  UTSecure2K4 - Interim security 2K4 styles version: 1.11
ScriptLog:  (c) 2002-2004, Epic Games
ScriptLog: =================================================================
ScriptLog:  * Logging Cheaters
ScriptLog:  * Tracking Post-login package loading
ScriptLog:  * Timeout: 60 (Log when expired)
ScriptLog: =================================================================
ScriptLog: 
NetComeGo: Open myLevel Fri Aug  4 21:41:10 2006 193.135.144.178:3737
NetComeGo: Open myLevel Fri Aug  4 21:41:10 2006 84.58.146.244:19696
Log: MasterServerUplink: Resolved ut2004master2.epicgames.com as 207.135.145.7.
Log: Resolved master0.gamespy.com (207.38.11.34)
ScriptLog: UdpGameSpyUplink: Master Server is master0.gamespy.com:27900
ScriptLog: UdpGameSpyUplink: Port 7788 successfully bound.
Log: Client netspeed is 10000
Log: Client netspeed is 9636
Log: MasterServerUplink: Connection to ut2004master2.epicgames.com established.
NetComeGo: Open myLevel Fri Aug  4 21:41:10 2006 193.135.144.178:3739
Log: Approval APPROVED
Log: Master server requests heartbeat 0 with code 1388
Log: Master server requests heartbeat 1 with code 1388
Log: Master server requests heartbeat 2 with code 1388
NetComeGo: Open myLevel Fri Aug  4 21:41:13 2006 84.58.146.244:9253
Log: Master server assigned our MatchID: 0
NetComeGo: Close TcpipConnection 84.58.146.244:9253 Fri Aug  4 21:41:13 2006
ScriptLog: New Player -KM-Roadrunner id=92ae1418034d908122fb16a17e21445e
ScriptLog: [Nothing to Secure] -KM-Roadrunner
ScriptLog: START MATCH
ScriptLog: New Player -KM-Igno id=5a9c427fdaea65f2be0fb1735a898ccd
Log: Close: Error while attempting to close socket.

Die letzte Zeile wiederholt sich dann, bis man mit ner zweiten SSH-Verbindung des Server abschießt.

Achso, und die Zeile mit dem Bind error sieht, wenn sie auftritt, so aus:

Code: Alles auswählen

WebAdmin: xWebAdmin.UTServerAdmin Initialized on port 7771: Bind error