Sie sind nicht angemeldet.

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

1

Donnerstag, 9. Februar 2012, 18:42

Counter-Strike: Source Deathmatch crasht random

Liebe Board User vielleicht gibt es schon Threads die dieses Problem lösen/beschreiben/angehen, aber ich bin nicht fündig geworden.
Also es geht um folgendes


Ich bin seit neuem Betreiber eines CSS:DM Servers und der läuft auch relativ gut.
Sooo ich musste heute aber mit bedauern feststellen, dass CSS:DM Random crasht nach mal 45 Minuten... 1 Stunde... fast 2 Stunden, dass ist natürlich nicht angenehm für die Spieler.
Ich dachte zunächst an die cssdm.games.txt, wo ich meines erachtens die neuste Version habe
Diese hier: http://forums.alliedmods.net/attachment.…97&d=1320709276

Es ist ein Linux Dedicated Server:

Linux: Debian Wheezy 7.0
Sourcemod: Sourcemod-1.5.0-hg3456
Metamod: 1.9.0-hg768
CSS:DM: CSS:DM-2.1.5-hg77
Load Average: 0.00 - 0.01 wenn 28 Spieler drauf sein
Kernel: 3.0.0 100 HZ

Ich würde mich sehr darüber freuen, wenn jemand schon eine Lösung hat und mir helfen kann ^^
Schon mal danke im vorraus

EDIT:

Log entry vom /var/log/kern.log:

Feb 9 18:18:49 Bumblebee kernel: srcds_linux[5965]: segfault at 8 ip 00000000f3c44584 sp 00000000fffebfec error 4 in server.so[f385c000+59b000]

Crash log entry vom Gameserver:

./srcds_run: line 372: 5965 Segmentation fault (core dumped) $HL_CMD
BFD: Warning: /home/dust2deathmatch/css/core is truncated: expected core file size >= 312705024, found: 1163264.
Cannot access memory at address 0xf77f5908
Failed to read a valid object file image from memory.
Cannot access memory at address 0xfffebfec
Cannot access memory at address 0xf77f5908
debug.cmds:5: Error in sourced command file:

EDIT 2:

Bereits unternommene Versuche das Problem zu lösen, leider ohne Erfolg:

- Neuste Version von glibc
- server.so und dedicated.so gelöscht und durch -verify_all wieder downloaden lassen
- Neuste Snapshotversionen
- Sourcemod Stable Versionen getestet sowie CSS:DM Stable
- Server mit ROOT Rechten starten
- Arbeitsspeicher Test durchgeführt... Keine Fehler

Ich bin echt am Ende mit meinem Latein ;(

MFG
ProfDrRoot

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »ProfDrRoot« (9. Februar 2012, 19:54)


Beiträge: 1 537

Wohnort: Krefeld

Beruf: Student

Rootserver vorhanden: Nein

  • Nachricht senden

2

Donnerstag, 9. Februar 2012, 19:06

Versuch mal bitte einen Check des Arbeitsspeichers durchzuführen. Ich meine das müsste Memcheck sein.
Glaube aber nicht, dass es daran liegen wird. Vermutlich ist es ein Plugin, dass eine fehlerhafte Abfrage im Ram verursacht,
also bitte alle Plugins in SM auflisten. Sollte eigentlich nicht am DM liegen.
LG
GeNeRaLbEaM

Wer Rechtschreibfehler findet, darf sie behalten.

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

3

Donnerstag, 9. Februar 2012, 19:55

So der RAM wars auch nicht er hat auch eine ECC Funktion.
Ja zu den Plugins, dass werd ich mal durchprobieren und werde mich dann wieder melden falls es erfolglos war :)

fluxX

Super Moderator

Beiträge: 1 056

Wohnort: Österreich

Beruf: IT Systemadministrator

Rootserver vorhanden: Ja

  • Nachricht senden

4

Donnerstag, 9. Februar 2012, 21:44

was mir noch einfällt ist:

lade diese CSSDM Version auf deinen Server: Link
und ersetzte die cssdm.games.txt mit dieser: Link

sollte dann funktionieren.

5

Donnerstag, 9. Februar 2012, 23:00

Ich würde mir überlegen an Stelle von "Unstable" "Stable" zu verwenden. Den Namen hat Debian 7.0 nicht ohne Grund. 7.0 wird wahrscheinlich erst nächstes Jahr zur "Stable".
Im produktiven Servereinsatz hat 7.0 demnach nichts zu suchen.
Webbasierender Config Ersteller: www.ulrich-block.de für CS 1.6, CSS, DODS und TF2.

Ebenso wird werden verschiedene Debian Gameserverkernel zum Download angeboten.

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

6

Donnerstag, 9. Februar 2012, 23:25

@ Terror Karotte

Da hast du Recht, aber das hat nichts mit den Crashs zu tun.
Debian 7.0 habe ich ausgibig auf meiner Server-Ebene zu Hause getestet und es läuft wunderbar
Es trennen sich hier wieder die Meinungen von Systemadministratoren ;)
Aber um Debian 7.0 auszuschließen Terrorkarotte wurde der Server auch auf 5.0 Lenny und 6.0 Squeeze getestet bei mir daheim.
Crashen tut er immer wieder nach 0,5 - 1,5 Stunden -.-

@ fluxX

Wir benutzen schon diese Kombination :D

7

Freitag, 10. Februar 2012, 01:45

Schau dir doch am Besten mal an, wo die Crashursache liegt.
Mit dem Benutzer, mit dem du den Server startest das Größenlimit der coredumps entfernen

Quellcode

1
ulimit -c unlimited

und den Gameserver mit

Quellcode

1
-debug -nobreakpad
in den Startparametern starten.

Wenn der Server nun crasht, hast du einen schönen ungetrimten core.xxxxx dump in deinem Serververzeichnis bei der srcds_linux binary.
Diese dann mit

Quellcode

1
gdb srcds_linux core.xxxxx
laden und in der gdb Konsole "bt" eingeben. Im Backtrace siehst du dann ganz oben die Datei und hoffentlich auch Methode, in der der Crash aufgetreten ist.

https://developer.valvesoftware.com/wiki…ing_under_Linux

Metamod 1.9.0 ist instabil und nicht für den produktiven Einsatz geeignet iirc.
Benutzt du irgendwelche Plugins, die zwingend SourceMod 1.5.0 benötigen, oder wieso bleibst du nicht bei den stabilen Releases?

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

8

Freitag, 10. Februar 2012, 07:27

Danke für deinen Ratschlag Peace-Maker ich werde die von dir aufgeführten Aktionen mal durchführen ^^
Ich benutze sie deshalb, weil ich damit noch nie Probleme hatte und die Snapshotversionen nach einem Update meinstens noch funktionieren nicht so das stable Release.
Aber wenn du meinst, dass dies helfen soll werde ich mal deine Kombination aus Befehlen und den Stable Sourcemod, wie Metamod Versionen ausprobieren und hier eine Rückmeldung geben :).

Beiträge: 881

Wohnort: L.E.

Beruf: KiN im Betriebsdienst

Rootserver vorhanden: Nein

  • Nachricht senden

9

Freitag, 10. Februar 2012, 11:22

Ich hätte jetzt spontan auf RAM getippt, da wir ähnliches Problem Anfang Januar hatten und aktuell jetzt auch wieder. ECC heißt aber nicht das der RAM trotzdem einen weg hat ;).
24/7 Teamspeak³ Server:


Linux is like a wigwam → No windows. No gates. Apache inside.

1. Frage des Admin: was wurde vorher verändert?
2. Antwort des Users: nichts
3. Frage des Admin: was wurde verändert, bevor NICHTS verändert wurde?

Ene mene muh gebasht wirst du,
ene mene miste headOr durch die Kiste,
ene mene meck kaum siehste mich schon fliegste weg :D

Beiträge: 2 498

Wohnort: Schwelm

Beruf: Immobilien-Verwalter / Serveradministrator

Rootserver vorhanden: Nein

  • Nachricht senden

10

Freitag, 10. Februar 2012, 11:52

Ich würde auch auf RAM oder einen fehlerhaften Kernel tippen. Habt ihr den mal bearbeitet?

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

11

Freitag, 10. Februar 2012, 13:23

Der Ram ist es nicht da der MemCheck nichts ergab.
Die anderen Gameserver bei mir funktionieren ja auch, wenn der Ram also am Arsch wäre würde die anderen auch rumzicken oder nicht ?
Der Kernel ist auch ausgeschlossen habe ihn zwei mal neu kompiliert ohne Fehler hab den Vorgang strengstens nach vollzogen.
Ich werde gleich nach dem Mittag :D erstmal die Möglichkeiten von Peace Maker durchgehen die scheinen mir momentan als einzigster Lichtschein am Ende der Dunkelheit xD

MadMakz

Super Moderator

Beiträge: 1 878

Wohnort: ~#

Rootserver vorhanden: Ja

  • Nachricht senden

12

Freitag, 10. Februar 2012, 13:30

echt jetzt?

das gesammte system läuft mit unstable releasen (OS, MMS, SM) und es wird sich gewundert das das system/spiel nicht stabil läuft???

und dann auch kein plan vom debugging?


nighlys sind dazu da um entweder:
release zu testen, im debug level, um hersteller zu unterstützen oder seine eigenen plugins vorweg zu portieren/verbessern.
oder
zur not als workaround falls "stable" nicht mehr funktioniert, in solch einem fall wird aber generell nur zur nächst höheren version geswitcht.

beide fälle sehe ich hier nicht gegeben, so,

pointless topic is pointless.

btw:

Zitat

Cannot access memory at address 0xf77f5908
Failed to read a valid object file image from memory.
Cannot access memory at address 0xfffebfec
Cannot access memory at address 0xf77f5908

hat in 99.999% der fälle nichts mit defektem RAM bzw. nicht mit hardware defekten generell zu tun.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »MadMakz« (10. Februar 2012, 13:38)


Beiträge: 1 537

Wohnort: Krefeld

Beruf: Student

Rootserver vorhanden: Nein

  • Nachricht senden

13

Freitag, 10. Februar 2012, 13:38

Ja die Fehlermeldung in Google gibt zwar Treffer aber auch keine Schlüssigen Antworten. Sieht nach EInzelfällen aus.
Villeicht auch nur eine Anernanderreihung von Fehlern. Ich tippe immer noch auf ein Fehlerhaftes Plugin weil der Nackte Server ja läuft.
Ich würde alle Plugins runterschmeißen und dann anfangen zu testen. Nur SM / MMS, dann mit DM und dann immer weitere einzeln dazu laden und schauen was den crash verursacht.
Wenn es natürlich das DM Plugin selber ist, dann haste ein Problem.
LG
GeNeRaLbEaM

Wer Rechtschreibfehler findet, darf sie behalten.

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

14

Freitag, 10. Februar 2012, 13:46

@ MadMakz Wie gesagt liegt es nicht an dem OS... Debian Lenny 5.0.4 sowie Debian Squeeze 6.0.1 geben den selben Fehler raus auch bei Stable Metamod und Sourcemod Versionen.

Beiträge: 2 498

Wohnort: Schwelm

Beruf: Immobilien-Verwalter / Serveradministrator

Rootserver vorhanden: Nein

  • Nachricht senden

15

Freitag, 10. Februar 2012, 14:00

Also unser DM läuft ohne Probleme.

Wir nutzen allerdings nur die offiziellen Versionen von

SM 1.4.1
MM 1.8.7
CSSDM 2.1.4.

dazu sogar noch die kritischen Eventscripts.

v2.1.1.370

Keine Crashes, keine Probleme. Wenn´s nicht unbedingt sein muss, vermeide ich .dev Versionen konsequent.

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

16

Freitag, 10. Februar 2012, 14:07

Templettonpeck würdest du mir deine cssdm.games.txt anhängen ? Vielleicht ist meine ja auch fehlerhaft ?
Ich werde dann mal einen Server mit deiner Kombination aufsetzen und gucken, ob der sich stabil hält ^^

MadMakz

Super Moderator

Beiträge: 1 878

Wohnort: ~#

Rootserver vorhanden: Ja

  • Nachricht senden

17

Freitag, 10. Februar 2012, 14:18

Stable

kk, hatte deinen "edit 2" nicht bemerkt da ich das topic gestern schon gelesen hatte aber keinen bock zum posten hatte.

anyway, hast du peace-maker's debug anleitung mal gemacht?

ProfDrRoot

Anfänger

  • »ProfDrRoot« ist der Autor dieses Themas

Beiträge: 8

Wohnort: Meppen

Rootserver vorhanden: Ja

  • Nachricht senden

18

Freitag, 10. Februar 2012, 14:30

Den core hab ich jetzt auf unlimited, wenn der Server gleich crashen sollte wegen Uptime = 1Stunde da stürzt er immer ab gestern waren max 1h 45 min dann setz ich die Startparameter dazu und dann hoffe ich mal das Problem ist gegessen :D

Beiträge: 2 498

Wohnort: Schwelm

Beruf: Immobilien-Verwalter / Serveradministrator

Rootserver vorhanden: Nein

  • Nachricht senden

19

Freitag, 10. Februar 2012, 18:01

Bitteschön... :thumbup:
»templetonpeck« hat folgende Datei angehängt:
  • cssdm.games.txt (4,74 kB - 173 mal heruntergeladen - zuletzt: 22. April 2024, 14:10)

DeaD_EyE

Administrator

Beiträge: 3 980

Wohnort: Hagen

Beruf: Mechatroniker (didaktische Systeme)

Rootserver vorhanden: Nein

  • Nachricht senden

20

Samstag, 11. Februar 2012, 09:07

@ Terror Karotte

Da hast du Recht, aber das hat nichts mit den Crashs zu tun.
Debian 7.0 habe ich ausgibig auf meiner Server-Ebene zu Hause getestet und es läuft wunderbar
Es trennen sich hier wieder die Meinungen von Systemadministratoren ;)
Aber um Debian 7.0 auszuschließen Terrorkarotte wurde der Server auch auf 5.0 Lenny und 6.0 Squeeze getestet bei mir daheim.
Crashen tut er immer wieder nach 0,5 - 1,5 Stunden -.-

@ fluxX

Wir benutzen schon diese Kombination :D


Also ich hätte eher mal versucht von SM und MM den stable Release zu nehmen. Neuer =! besser. Gerade bei SM kann es vorkommen, dass verschiedene Funktionen im Snapshot nicht getestet sind. Das erhöht die Wahrscheinlichkeit von Abstürzen. Meist laufen die stable Releases auch besser nach einem Serverupdate, wenn die gamedata aktualisiert werden kann.

CS:S bringt soweit ich weiß auch eine eigene glibc mit, die sich im Verzeichnis css/bin befindet. D.h. es wird die vom System nicht genutzt. Schau einfach mal in css/bin nach. Es müssten auch andere Libs drin sein, die eigentlich besser im System selbst aufgehoben wären. Durch LD_LIBRARY_PATH werden alle Libs immer zuerst in ./ und dann in ./bin gesucht.