Messages

Ich glaub ich hab da was missverstanden ^^

ich hab halt die vermutung dass der bot versucht die clients festzustellen und dabei die ganze tabelle durchsehen will und dann in ein timeout rennt bzw. die verbindung zum ts deswegen nicht mehr halten kann.

Habe den Log gelöscht und er rennt trotzdem in Timeout. Daher ziehen wir jetzt erstmal um

Ok das machen wir mal.

Die Logtabelle in der DB hat über 500k Einträge. Wohl seitdem geloggt wo du mir das erste mal vor Jahren geholfen hast den aufzusetzen  willst du diesen historischen Log erhalten bevor wir ihn löschen?

Ok

Frage zur MySQL DB:

Die hat ein Volumen von 60 MB.
Ist das schon überlaufen? Oder ist das nicht relevant?

Wir ziehen gerade den Bot um auf unsere TS3 VM. Das Webinterface bleibt dann auf dem Root.
Mal schauen was das bringt.

Danke Stefan das hilft uns weiter 

Dann ist unsere neue Zielführung den bot 24 Stunden mindestens am Leben zu erhalten.

Hast du dir die Screenshot ansehen können? Sagen dir die neuen Fehlermeldungen etwas?

Also wir haben etwas am VPN Tunnel geändert, andere Software auf der TS3 VM.

Jetzt ist der Bot 5 Stunden am Stück gelaufen und hat sich dann verabschiedet:

Zuerst die Meldung wenn er die Verbindung verliert:
https://chrizzzle.com/pics/1537455698.png

Dann die Meldung wenn die Verbindung weg ist:
https://chrizzzle.com/pics/1537455765.png

Die Clients hat er nicht gelöscht wie aufgetragen. Die Funktion will einfach nicht mehr.
Dafür haben wir jetzt neue Fehlermeldungen wie man anhand der Screenshots sehen kann.

Parallel dazu haben wir den Bot kopiert und auf eine Kopie von unserem TS gesetzt.

Die Verbindung zwischen den Kopien verläuft intern im Netzwerk, ohne VPN, da ein Root Server und zwei VMs. Der Bot läuft seit über 6 Stunden ohne Abbruch aber auf dem TS ist auch nichts los.

Unsere eigentliche Konfiguration ist die Bot VM auf unserem Root Server in Rechenzentrum X, verbunden per VPN mit einem VPS in Rechenzentrum Y.

Der Tunnel ist stabil und das Konzept fahren wir schon seit über 2 Jahren ohne Probleme.

Und es erklärt auch nicht warum die Clients nicht gelöscht werden, wenn sie x Tage nicht da waren. In unserem Fall 365. Das hatte am Anfang immer funktioniert.

Wir planen jetzt als nächsten Versuch den Bot auf den VPS zu setzen wo auch der TS3 Server ist, das webinterface bleibt aber auf dem Root weil der VPS zu wenig RAM für MySQL Server hat.

Trotz allem wäre es gut zu wissen warum die Clients nicht mehr gelöscht werden und was wir da beachten müssen.

Welche Möglichkeiten bleiben uns denn noch?

Was muss sichergestellt sein?

Was können wir noch prüfen?

So,

Der Log einer Woche liegt nun vor.

Welche Infos brauchst du noch?

Nun Stefan, wir nutzen den Bot jetzt auch schon ein paar Jahre und erst seit ein paar Monaten haben wir diverse Probleme.

Nicht nur mit deinem Bot. Wir hatten mit einer eigenen Entwicklung, einem Telegrambot das Problem, dass er nach exakt 5 Minuten sich verabschiedet hat. Wir haben den Timeout erhöht und nun geht es wieder.

Dann ist uns aufgefallen, das unser JTS3Bot mehrmals am Tag sich verabschiedet.
Wir haben gestern erstmal auf SSH umgestellt in der Hoffnung, dass es das Problem löst aber der Bot stürzt jetzt nur noch öfter als vorher ab.
Vorher waren es 2-3 mal am Tag, jetzt ist es mindestens einmal pro Stunde wenn viel betrieb ist auf dem TS3 Server.
Auszug aus Fehlerlog:
https://pastebin.com/ti4GkD3a

Dann haben wir festgestellt, dass der Bot genau nachdem er die Clientliste geladen hat sich verabschiedet, nicht immer aber öfters.
Das würde auch erklären warum er unsere Servergruppen nicht mehr aufräumt und inaktive User löscht.
Das automatische löschen funktioniert auch nicht mehr. Die User bleiben bestehen.
Hier ein paar Auszüge aus dem Log:
https://pastebin.com/zAtzBfn0

Ich möchte betonen, dass wir das Problem schon seit ein paar Monaten haben und an den Funktionen nichts verändert wurde. Der Bot lief immer ohne Probleme. Das Update von Version aus 2016 (ja ich bin Faul was das betrifft ) in die aktuelle vom 21.08 hatte auch keine Abhilfe gebracht.
Linuxupdate auf der TS3 VM wurden vor kurzem durchgeführt, Serverversion TS3: Version:3.3.1 (20.08.2018 10:19:20)

Der JTS3Bot selbst läuft zusammen mit dem Webinterface auf einem 2016er Windows Server (VM), schon seit fast einem Jahr, davor 2012.

Was mir an unserem Log aufgefallen ist, er reicht bis ins Jahr 2015 zurück, 2105 Seiten a 200 Zeilen
Vielleicht kann man den extrahieren und komplett zur Verfügung stellen.
Der Fehlerlog geht auch zurück bis ins Jahr 2015.

Der TS3 Serverlog ist wie immer sehr Aussagekräftig:
2018-09-18 13:43:02.141536|INFO    |VirtualServerBase|1  |query client disconnected 'Kartoffel-Butler'(id:1) reason 'reasonmsg=connection lost'

Welche Troubleshooting Möglichkeiten gibt es noch, die ich vielleicht übersehen hab?
Konnte man nicht irgendwo den Cache leeren von dem Bot?

Ich hoffe, dass wir das Problem irgendwie gelöst bekommen


Gruß

André

Egal Ich habe es jetzt so gelöst.

Quick and Dirty ^^

Danke dir trotzdem!

Komisch. Frage mich warum die Meldung dann nicht mehr auftaucht

Ok. Dann löse ich es mit der zweiten Idle Check Funktion mit der Warnung.

Solange sollte man das überbrücken können

Der "Zufall" wurde aber nach jedem Botneustart angezeigt. Erst als ich "Guest" herausgenommen habe, war dieser Log Eintrag / Fehler weg nach erneuten Botstarts und Stopps.

In der Servergruppe Guest sind ja auch keine Clients gelistet. Daher macht die Meldung sofern Sinn

Nope.

Hallo Welt, ohne Schnickschnack.

Bekomme keine Nachricht. Habe natürlich den Bot komplett neu verbunden.

Hier ein Log Auszug indem man sieht das eine andere Idle Check Funktion geht was Messages angeht. Diese andere Funktion verschiebt den Client nach 60 Min.

Meine Testzeit für den Idle Check mit Servergruppe AFK ist auf eine min gestellt.

Theoretisch könnte ich die Benachrichtung nach 50 min (im Produktiveinsatz soll der Bot nach 50 min AFK Gruppe Setzen und nach 60 min AFK moven) auch über die zweite Idle Check Funktion machen (Warnung) aber das ist aber unschön.


07.12.2016 18:42:24    IdleAFKGruppe    Information    Added client "Verden1992 @ Work" (db id: 34) to server group id 173 for being idle!
07.12.2016 18:41:36    Idle    Information    Client "maximilian" (db id: 1082) was idle, client was moved and got a message!
07.12.2016 18:41:21    JTS3ServerMod    Information    Server connection log is activated and will be written into the MySQL database
07.12.2016 18:41:21    JTS3ServerMod    Information    Creating client database cache...

Gut, dann bin ich mal gespannt.

Btw. mir ist noch ein kleiner Bug aufgefallen.

Profis sollte klar sein das man die Standard Servergruppe "Guest" nicht überprüfen kann auf untätige Clients.

Da ich aber kein Profi bin oder mal wieder dumm gewesen bin, ist mir natürlich der Log Eintrag aufgefallen:

07.12.2016 15:15:20    JTS3ServerMod    Kritisch    Error while getting client list!
07.12.2016 15:15:20    JTS3ServerMod    Fehler    java.lang.IllegalStateException: Closed TS3 Connection: java.net.SocketException: Connection reset
07.12.2016 15:14:33    JTS3ServerMod    Status    Activate log level: INFO
07.12.2016 15:14:33    JTS3ServerMod    Status    Virtual bot instance "Kartoffel-Test" starts now (build 6300)


Zuerst dachte ich es liegt an der zu großen DB. Aber nachdem ich die Servergruppe "Guest" aus der Funktion herausgenommen habe, kam der Fehler nicht mehr.

Sollte man vielleicht drauf hinweisen oder ausblenden die Gruppe in der Funktion