Moin
Seit der letzten Version vom Bot wobei ich auch gleich den TS Server auf die neuste Version gebracht habe bricht jetzt immer bei Zeiten die Verbindung ab mit der Meldung
java.lang.IllegalStateException: null object, maybe connection to TS3 server interrupted.
Jetzt habe ich schon etwas umgeschaut könnte das was hiermit zu tun haben?
https://forum.teamspeak.com/threads/136623-Query-idle-no-longer-working
Gruß
Eiki
Sobald du eine der folgenden Funktionen aktiviert hast, ist der Bot niemals idle:
AwayMover
MuteMover
IdleCheck
RecordCheck
BadNicknameCheck
Ist keine von den genannten Funktionen aktiv, schickt der Bot trotzdem alle 60 Sekunden zwei Befehle raus, um die Channel und Servergruppen Namen zu cachen. Insofern sollte das Problem nie bestehen, da die Idle Timeout Zeit vom TS3 Server glaube über 60 Sekunden liegt (früher bei 600 Sekunden).
Ja die Funktionen sind fast alle an ich hatte mir das auch schon gedacht das er wohl mehr Befehle schickt aber hast sonst ne Idee ob das am Bot liegen könnte oder mehr am TS Server.
Naja, ich mache ja schon seit Jahren keine eigenen Langzeittests mehr, da ich keinen aktiven TS3 Server mehr betreibe. Allerdings nutzen nun schon mehrere Personen die JTS3ServerMod Version 6.5.0 und bisher hat sonst noch niemand das Problem gemeldet. Womit ich aktuell nicht davon ausgehe, das es am JTS3ServerMod liegt.
Nutzt du den SSH Modus, oder den RAW Modus? Der SSH Modus ist natürlich noch nicht so intensiv getestet worden.
Hab gestern auf SSH umgestellt, ich könnte es wieder umstellen um zu testen ob es dann nicht mehr passiert.
Werde dies mal machen und 24 Stunden warten ob es wieder passiert. Werde mich dann hier wieder melden.
Mir ist gerade noch etwas aufgefallen ich schreibe das mal hier damit brauch ich nicht noch ein extra Thema auf machen. Ich habe gerade festgestellt das die Channel Überwachung nicht geht ich habe an den Einstellungen bestimmt seit 2 Jahren nicht verändert und auch gerade noch einmal durchgesehen das ist alles richtig trotzdem bekommt man keine Nachricht wenn ein Spieler in den entsprechenden Channel geht. Wurde dort etwas geändert?
Quote from: Eiki on August 22, 2018, 05:18:23 PM
Mir ist gerade noch etwas aufgefallen ich schreibe das mal hier damit brauch ich nicht noch ein extra Thema auf machen. Ich habe gerade festgestellt das die Channel Überwachung nicht geht ich habe an den Einstellungen bestimmt seit 2 Jahren nicht verändert und auch gerade noch einmal durchgesehen das ist alles richtig trotzdem bekommt man keine Nachricht wenn ein Spieler in den entsprechenden Channel geht. Wurde dort etwas geändert?
Habe mich gerade per SSH zu meinem TS3 3.3.0 Testserver verbunden. ChannelNotify (Channel Überwachung) funktioniert einwandfrei.
Sorry der Fehler mit der Benachrichtigung lag an mir ich hab einfach den Fehler übersehen vergiss das einfach xD
Ich glaube der Fehler das der Bot immer die Verbindung verloren hat lag am Linux es gab in den letzten Wochen immer wieder Linux Updates und nach einem Update spinnten auch ein paar andere Programme die das Netzwerk verwenden. Jetzt habe ich heute morgen wieder ein Linux Update gemacht und zack bei allen Programmen sind die Fehlermeldungen verschwunden und auch der Bot läuft jetzt jetzt sauber durch.
Sehr gut :)
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 :D ) 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 :D
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é
Bitte die komplette Log (nicht nur Fehler und Warnungen), gerne vorher die Einträge älter als 1-2 Tage löschen (wird auf der Seite angeboten) und herunterladen (siehe Link oben).
So,
Der Log einer Woche liegt nun vor.
Welche Infos brauchst du noch?
Als Randnotiz Teamspeak hat den Standart Timeout für den Query auf 5 Minuten gesetzt.
Quote from: Erzarocks on September 19, 2018, 06:08:51 PM
Als Randnotiz Teamspeak hat den Standart Timeout für den Query auf 5 Minuten gesetzt.
Wäre bzgl. JTS3ServerMod unspannend, da mindestens alle 60 Sekunden mehrere Query Befehle abgesetzt werden.
@ André: Die Unterbrechungen sind total willkürlich, von 15 Minuten bis 15 Sekunden nach der letzten Aktion ist ja alles an Zeiträumen dabei. Sehr kurios. Letztendlich werde ich da wenig machen können. Der JTS3ServerMod stellt ja völlig korrekt fest, dass die TCP Verbindung unterbrochen wurde. Solange mir jetzt nicht gleich 100 Leute schreiben, dass die das selbe Problem haben, sehe ich das Thema nicht beim JTS3ServerMod.
Welche Möglichkeiten bleiben uns denn noch?
Was muss sichergestellt sein?
Was können wir noch prüfen?
Von Fehler im Betriebssystem oder der Java VM, Firewallkonfiguration, bis hin zu Fehler im TS3 Server ist alles möglich. Ich habe keine Idee. Natürlich möchte ich auch keine Fehler im JTS3ServerMod ausschließen, würde dann hier aber mehr betroffene Anwender erwarten.
Habe es gerade mal bei mir unter Windows mit dem TS3 Server Version 3.4.0 (10.09.2018 09:29:44) und der SSH Verbindung getestet:
On this server runs JTS3ServerMod 6.5.0 Hosting Edition (28.08.2018) since 1:27:33 hours.
Es ist also definitiv kein generelles Problem.
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.
Quote from: André on September 20, 2018, 05:17:36 PM
Die Clients hat er nicht gelöscht wie aufgetragen. Die Funktion will einfach nicht mehr.
[...]
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.
[...]
Trotz allem wäre es gut zu wissen warum die Clients nicht mehr gelöscht werden und was wir da beachten müssen.
Dazu kommt er ja nicht, da er dafür mindestens 24 Stunden online sein muss. Ist ein interner chronjob für alle 24 Stunden.
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?
Naja, wenn der TS3 Server 40 Sekunden lang nicht reagiert, wird die Verbindung wegen Timeout getrennt. Warum der TS3 Server 40 Sekunden lang nicht geantwortet hat, weiß ich nicht und wird der JTS3ServerMod leider auch nicht erfahren. :(
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.
Das meiste werden die Logs sein. Die kannst du ja vom Bot immer nach 10 Tagen oder so löschen lassen (eine Einstellung in der JTS3ServerMod_InstanceManager.cfg Datei).
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 :D willst du diesen historischen Log erhalten bevor wir ihn löschen?
Quote from: André on September 20, 2018, 07:46:23 PM
willst du diesen historischen Log erhalten bevor wir ihn löschen?
Lass mal ;)
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
Quote from: André on September 20, 2018, 08:00:22 PM
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.
40 Sekunden? Das müssten dann einige Hunderttausend Clients sein, die gerade online sind. ;)
Ich glaub ich hab da was missverstanden ^^
So,
Wir haben den Bot direkt auf die TS3 VM gepackt inklusive MySQL db.
Das Webinterface liegt auf dem Root.
Trotzdem kommen Verbindungensabbrüche:
https://chrizzzle.com/pics/1537475504.png
Was können wir noch tun?
Wie lange läuft dein Bot jetzt schon?
Quote from: André on September 20, 2018, 10:35:40 PM
Wie lange läuft dein Bot jetzt schon?
Naja, den hatte ich kurz danach aus gemacht, weil mein PC ja nicht 24/7 läuft.
Das Problem hast du ohne SSH auch?
Wenn du es benötigst können wir dir eine VM stellen kostenfrei :)
Windows und / oder Linux. Dann können wir nach all den Jahren auch mal was zurückgeben und man könnte dir für Langzeitests eine Kopie unseres TS3 Server zur Verfügung stellen regelmäßig. Den Root betreiben wir zuverlässig seit 3 Jahren und Ressourcen sind genug verfügbar!
Zurück zum Thema:
Wir wollen jetzt zum nächsten Versuch übergehen Und den Bot lokal per Telnet verbinden lassen. Melde mich wenn das erfolgt ist.
Wenn das auch keinen Erfolg bringt, kommt die Holzhammer Methode:
Ich kopiere das Webinterface und setze einen komplett neuen bot auf, alles ganz frisch mit neuer DB. Dann alle Funktionen per Hand nachbauen / kopieren.
Oder hast du noch eine bessere Idee bevor wir alles platt machen?
Du kannst auch die Datenbank übernehmen, das Problem wird nicht durch eine Bot Funktion verursacht.
Der SSH Modus ist natürlich noch nicht so etabliert, aber da nutze ich eh eine fremde Bibliothek, da bin ich nicht so flexibel. Teste mal bitte, ob beim normalen unverschlüsseltem Query Modus das Problem ebenfalls auftritt.
Wir haben in der config jetzt noch Localhost definiert.
Er läuft immer noch auf ssh seit 14:07 ohne Fehler und Abstürze. Wir sind gespannt ob er bis morgen Mittag durchhält und Clients löscht.
Er hat es um 14:29 geschafft über 9000 Clients in den DB Cache zu laden. Das hat vorher Stunden gedauert und direkt danach mit Absturz.
Es sieht also sehr gut aus bisher :)
Und es läuft wieder :)
Lag wohl echt am VPN Tunnel. Der hat die letzten Jahre immer zuverlässig funktioniert :/
Jedenfalls wurden ein paar tausend Clients gelöscht ;)
Thema also erledigt!
Danke für deine Hilfe!
Das Angebot mit der VM steht noch wenn du möchtest!
Das ist doch super, wenn ohne VPN wieder alles funktioniert.