Musikbots stürzen unregelmäßig ab

[KartoffelStampfer]

Hallo zusammen,

ich habe das Problem das die 12 Musikbots (10 plus 2 Demobots) unregelmäßig die Verbindung verlieren zum TS3 Server.
Weder der TS3 Bot noch der Intanz / Bot Log sind für mich aussagekräftig genug.


Im Webinterface habe ich für jede Instanz alle Checkboxen angehakt außer "Channel-Commander" und und "Songs ankündigen".

Alle Bots haben eine Servergruppe mit welcher sie Anti Flooding ignore Rechte besitzen.


Meine Version ist die 0.9.12-be920c0.
Ich habe nicht die aktuellste Beta genommen, da die jüngere Version bei mir noch mehr Probleme bereitet hat. Dort konnten 3 von 12 Bots nach dem ersten mal Verbinden nicht mehr starten, egal ob ich das komplette Programm oder VM rebootet hab, sie kamen nicht online.

Die VM habe ich gestern frisch mit Debian 8 installiert.

Das System ist auf Hyper-V vitualisiert, hat virtuelle 4 CPU Kerne und 4 GB RAM. Der Prozessor des Root Servers ist ein E5-1650.

Als Browser nutze ich den aktuellsten Firefox, denke mal das es nicht mit meinem Problem zusammenhängt

RAM ist genug verfügbar wenn alle Bots laufen (minimum 2 GB) und HDD sind 50 GB frei.

Die Config.ini habe ich hier mal als .txt hochgeladen, da ich keine .ini Datei hier hochladen konnte.


Damit die übersicht gewährt bleibt, lade ich die log Datei und die Ausgabe von dem Diagnose Script bei Pastebin hoch.

Log Datei mit Loglevel 10 (die Logeinträge passen nicht zum Zeitpunkt des Absturzes: 12:06): http://pastebin.com/vpGJGdh0

Konsolen Auszug: http://pastebin.com/tRY3pUQG

Diagnose Script Output: http://pastebin.com/uQZwBLjn

Auszug aus dem WE (Instanz Log): http://pastebin.com/P1HtY0zt


Auffälligkeiten gibt es noch im ts3soundboard Ordner. Dort wurden unter Root Rechten eine "OK" Datei ohne Inhalt und ein "libglib:" Datei ebenfalls ohne Inhalt angelegt.

Kp was das zu bedeuten hat.

Ich hoffe ihr könnt mir weiter helfen

Gruß
André

 

[KartoffelStampfer]

Habe mich mit einem Freund auch nochmal darüber unterhalten.

Er meinte das diese beiden Meldungen ihm sorgen machen (Auszug aus dem Instanz Log):

2016/07/29 12:08:21 540b3e86 0a5a5722 INFO TS |ERROR |SoundBckndIntf| |libpulse.so.0: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
2016-07-29T12:08:21+02:00 TS |ERROR |SoundBckndIntf| |libpulse.so.0: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden

 

[mxschmitt]

Das ist normal, mit den Fehlern. Solch ein Problem hat bis jetzt meines Wissens nach noch keiner gehabt. Hast du eine Firewall oder ähnliches in deinem Netzwerk?

 

[KartoffelStampfer]

Ich hab jetzt mal ein bißchen rum probiert. Wenn ich z.B. nur 3 Bots verbinde dann laufen die auch. Alles darüber hab ich nicht getestet. Ich denke es hat mit der Masse zu tun.

Wir haben für teuer Geld extra eine Dauermitigation gegen DDOs Attacken gekauft, welche den TS3 Server von außen schützt.

Unser Netzwerk ist etwas komplizierter aufgebaut ^^ wir haben 2 Root Server und einen V Server.

Der V Server ist der nur für den TS3 Server da.

Der 1 Root ist im gleichen RZ wie der V Server.

Der zweite Root ist in einem anderen RZ. auf dem zweiten root ist auch die Sinus Bot VM.

 

[mxschmitt]

Update doch mal auf die neuste Beta

 

[KartoffelStampfer]

Die hatte ich, wie oben beschrieben schon drin :/ hat das problem nicht verbessert.
Ich vermute es liegt an der Dauermitigation.

Nächste Woche verschieben wir die VM ins RZ wo der TS3 Server auf einer Vm drauf ist. Dann kann man das vielleicht intern routen.

Was anderes fällt uns nicht ein.

 

[Xuxe]

Hi,

das kann schon sein das es Probleme mit der Mitigation gibt, unter anderem im First-Colo von Problemen gehört wenn z.B mehrere Instanzen gleichzeitig Connecten. Unsere eigenen Restrictions haben anfangs auch stress gemacht
Es kann aber auch das Limit sein von Teamspeak _ connections pending per ip _
Check das ab Wir können da leider nicht viel machen, da müsst ihr / euer RZ euch drum kümmern.

 

[KartoffelStampfer]

Hi,

danke dir für deine Hilfe @Xuxe.

Das connections per ip Limit ist nicht dran Schuld. Es liegt wohl an der Dauermitigation ^^

Wir versuchen das erstmal anders zu lösen, die vm ins FC RZ zu schieben und dann testen ob es läuft bevor wir an der Dauermitigation etwas ändern.

Zuviel Sicherheit kann auch einschränken