Moin
In der Config lässt sich ja einstellen das der Bot nach bestimmten Tagen die älteren Logs löscht z.b. wie bei mir
# Normal log entries older than X days will be deleted from MySQL jts3servermod_log table. 0 = disable auto delete!
mysql_log_delete = 90
# Connection log entries older than X days will be deleted from MySQL jts3servermod_log table. 0 = disable auto delete!
mysql_connection_log_delete = 90
Nach den Einstellungen sollten ja Logs die älter wie 90 Tage sind gelöscht werden.
Bei mir ist das aber seit neustem nicht mehr der Fall. Seit wann dies ist kann ich nicht genau sagen, es ist mir die Tage durch Zufall aufgefallen als ich etwas nachgucken wollte.
Bei mir bleiben alle Logs nicht länger wie 24 Stunden das stand heute Mittag im Botlog
2018-04-21 12:31:23 LOGGER_DELETE_LOG Deleted 32489 log entries successfully!
2018-04-21 12:31:23 LOGGER_DELETE_LOG Deleted 1231 connection log entries successfully!
Es gab in dem Zeitraum auch keine Fehlermeldung.
Heute Nacht gab es ein paar mal diese Meldung
2018-04-21 01:13:57 ERROR Unknown error catched at instance: bot1084_1
2018-04-21 01:13:57 JTS3ServerMod 6.4.3 Hosting Edition (17.12.2017): EXCEPTION
java.lang.ArrayIndexOutOfBoundsException: 6 >= 6
at java.util.Vector.elementAt(Vector.java:474)
at de.stefan1200.jts3servermod.JTS3ServerMod.e(Unknown Source)
at de.stefan1200.jts3servermod.JTS3ServerMod.b(Unknown Source)
at de.stefan1200.jts3servermod.o.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
ob dies damit etwas zutun hat weiß ich nicht ich wollte einfach nur schon so viele Infos hier rein schreiben wie ich finden konnte.
Ich hoffe es gibt für mein Problem mit den Logs eine Lösung oder ich habe einen Fehler den ich gerade nicht sehe.
Gruß
Eiki
War oder ist die Uhrzeit vom Server falsch?
Gerade noch mal nachgeguckt passt alles Datum und Uhrzeit.
Wird auch jede Nacht überprüft ob Datum und Uhrzeit richtig sind.
Dies ist aber immer schon so auf meinem Server gewesen.
schaue dir mal bitte die Zeitstempel in der Datenbank in der Log Tabelle an, enthalten auch Millisekunden. Passen die?
Was meinst du genau mit passen die? Ich habe dir hier einfach mal nen Screen gemacht.
Sind die letzten Einträge von eben.
(https://cubeimage.de/images/2018/04/21/wjAy.png)
Ok, die neusten Einträge haben auf jeden Fall den korrekten Timestamp. Was ist der älteste Eintrag?
PS: Diese Seite eignet sich gut dafür: https://www.epochconverter.com (die letzten drei Stellen aber weglassen, da der Unix Timestamp nur Sekunden enthält, keine Millisekunden).
Das ist der älteste Eintrag.
Your time zone: Samstag, 21. April 2018 12:31:24 GMT+02:00 DST
Hmm, den JTS3ServerMod Prozess schon mal neugestartet heute?
Jo gestern Morgen um die Zeit wo er dann heute die Logs gelöscht hat.
Gerade nochmal in den Source Code geschaut, also im Source Code ist alles richtig. An dem Teil des Source Code habe ich auch schon seit zwei Jahren (letzte Änderung März 2016) nichts mehr geändert und du bist der erste mit diesem Phänomen.
Die Frage ist, warum diese Berechnung einen falschen Wert ausspuckt:
System.currentTimeMillis() - (1000 * 60 * 60 * 24 * days)
Was hast du zuletzt am Server geändert, bevor der Fehler aufgetreten ist?
Das Problem liegt auch bei mir vor, wenn die beiden Einstellungen so sind
# Normal log entries older than X days will be deleted from MySQL jts3servermod_log table. 0 = disable auto delete!
mysql_log_delete = 90
# Connection log entries older than X days will be deleted from MySQL jts3servermod_log table. 0 = disable auto delete!
mysql_connection_log_delete = 90
Ich hab das ganze aktuell auf 0 gestellt, damit die Logs bestehen bleiben.
Ich hab halt 0 plan seit wann das ist das ist mehr durch einen Zufall aufgefallen aber ich kann mal etwas ausholen was ich alles verändert habe.
Mitte letztes Jahr habe ich auf Debian 9 umgestellt wo dann ja MySQL oder MariaDB ersetzte worden ist.
Java läuft bei mir seit dem 23.02.2018 die Version 1.8 Update 161 (Werde das gleich aber mal auf die 171 bringen).
Dann wurde noch alles auf PHP 7 umgestellt.
Und immer mal wieder Pakete installiert. Aber ich sehe in den Paketen jetzt keins was damit etwas zutun haben könnte.
Mag mal bitte einer testen, ob folgende Werte auch Probleme verursachen?
mysql_log_delete = 3
mysql_connection_log_delete = 3
Ich warte jetzt noch bis 12:31 Uhr weil dann sind wieder 24 Stunden rum da ich eben den Root mal neu gestartet habe und Java auf die neueste Version gebracht habe, danach kann ich das mal umstellen auf 3.
So eben ist nix passiert hab das jetzt mal auf 3 gestellt und den Bot neu gestartet dann warten wir mal ich melde mich.
Moin
so die ersten 24 Stunden sind rum und bis jetzt sieht es gut aus. Das stand eben im Log.
2018-04-23 12:55:30 LOGGER_DELETE_LOG Deleted 0 log entries successfully!
2018-04-23 12:55:30 LOGGER_DELETE_LOG Deleted 0 connection log entries successfully!
Jetzt mal abwarten was in den nächsten 2 Tagen passiert aktuell steht das Löschintervall noch auf 3 Tage.
Hmm, spannend. 90 Tage erzeugt aber eine Zahl, die locker noch als Java LONG oder MySQL BIGINT durchgeht (die verwendeten Datentypen auf dem Weg zum MySQL Server). Eigentlich sollte das keine Probleme verursachen. Aber wer weiß, wo auf dem Weg zum MySQL Server da murks raus kommt.
Bin trotzdem mal gespannt auf dein Testergebnis.
Hey
Ich habe mal über unser Problem mit einem gesprochen der sich sehr gut mit Java auskennt und er meinte hier ist der Fehler, das darf net so aussehen
System.currentTimeMillis() - (1000 * 60 * 60 * 24 * days)
Der rechnet in der Klammer als int daher läuft er an der stelle schon über du musst das an der stelle schon zum long machen so
System.currentTimeMillis() - (1000L * 60 * 60 * 24 * days)
dann passiert das nicht mehr.
Guter Hinweis, sobald ich von der Arbeit zuhause bin, teste ich das mal. Danke.
Moin
so Heute hat er wie gewollt nach den aktuellen Einstellungen Logs gelöscht
2018-04-24 12:55:30 LOGGER_DELETE_LOG Deleted 329 log entries successfully!
2018-04-24 12:55:30 LOGGER_DELETE_LOG Deleted 33 connection log entries successfully!
also 3 Tage scheint zu gehen. Wir haben gestern Abend noch mal bisschen gerechnet und wenn ich das noch richtig im Kopf habe müsste es bis 28 oder 29 Tagen in der Einstellung auch gehen danach läuft der Wert über.
Behoben in Version 6.4.4, welche ich gerade veröffentlicht habe.
Nice dann besten Danke. Gleich mal Updaten :)