- Affected App
- WoltLab Suite Core
Hallo WL,
mir ist folgendes auf gefallen das seit dem letzten Core Update einige Cronjobs nicht ausgeführt werden.
z.B. der Cronjob für die Gebrurtstags Benachrichtigungen.
Hallo WL,
mir ist folgendes auf gefallen das seit dem letzten Core Update einige Cronjobs nicht ausgeführt werden.
z.B. der Cronjob für die Gebrurtstags Benachrichtigungen.
Verwendest Du die aktuelle Version 3.1.5 pl 1?
Gruß norse
Ich hatte dasselbe Gefühl mit dem Cronjob zum Aktualisieren der Updates. Aber ich glaube das war bereits zwei Versionen vorher.
Das war vor nicht einmal zwei Wochen:
Cronjobs wurden manchmal unerwartet deaktiviert, das Problem wurde behoben und alle Cronjobs werden reaktiviert. 3.1.5 pl 1
Gruß norse
Das war vor nicht einmal zwei Wochen:
Gruß norse
Nein, das weiß ich.
Aber mir wurde Version 3.1.5 gar nicht zum Update angezeigt - zwei Tage später bzw nachdem 3.1.5 pl 1 auch draußen war - trotz aktiviertem Cronjob. War eventuell aber ein Hänger und ich habe es nicht näher untersucht, nachdem ich die Updates hier ja eh in der Regel zeitig mitbekomme.
Ja ich habe die aktuelle Version drauf.
Selbst UdoZ hat bei mir schon nach gesehen warum der Geburtstags-Cronjob trotz Aktivierung nicht läuft.
Und findet auch keine Lösung.
Bevor das in eine falsche Richtung geht:
Selbst UdoZ hat bei mir schon nach gesehen warum der Geburtstags-Cronjob trotz Aktivierung nicht läuft.
Es betrifft nicht nur den Cronjob. Seit Update auf WSC 3.1.5 pl 1 ist offensichtlich kein einziger Cronjob mehr durchgelaufen. Die Cronjobs sind aber alle aktiviert. Hinweise gab es im Protokoll (Fehler, Cronjobs) nicht. Ob es am Update liegt, kann ich nicht sagen. Auffällig ist aber eben der zeitliche Zusammenhang mit dem Update.
Auf allen Seiten gibt es einen 500er-Fehler mit Hinweis auf Ajax-Proxy / Cronjob-Ausführung. Dürfte der Grund für den 'Tod' der Cronjobs sein...
Also so wie ich das sehe, sind bei uns nach dem Update auf die 3.1.5 pl1 die Cronjobs durchgelaufen.
Bei uns laufen ebenfalls alle Cronjobs völlig normal, auch die vom Uzbot
Hmm, bei nem 500er Fehler muss man im Serverlog schauen was passiert, die kann das WSC so nicht abfangen.
Einen Zusammenhang mit dem Update konnte ich so zumindest bei uns nicht bemerken.
Tja ich weiß es auch nicht,
Da muss wohl Viktor mein Hoster auf dem Server nachsehen.
Hallo,
du musst auch mal in die Logs schauen.
Im Verzeichnis /logs gibt es eine Datei "error.log".
Fehler:
[Mon Sep 03 06:36:14.570870 2018] [proxy_fcgi:error] [pid 21449:tid 139754230347520] [client 87.122.211.103:56397] AH01071: Got error 'PHP message: PHP Fatal error: Allowed memory size of 419430400 bytes exhausted (tried to allocate 536870920 bytes) in /var/www/virtual/tourneo-forum.de/htdocs/cms/lib/util/CronjobUtil.class.php on line 518\n', referer: https://tourneo-forum.de/gallery/image-list/
Ich habe den erlaubten Speicher bei Dir mal erhöht.
Bitte die nächsten Tage mal anschauen ob es jetzt klappt.
Gruß
Viktor
Display MoreHallo,
du musst auch mal in die Logs schauen.
Im Verzeichnis /logs gibt es eine Datei "error.log".
Fehler:
Code[Mon Sep 03 06:36:14.570870 2018] [proxy_fcgi:error] [pid 21449:tid 139754230347520] [client 87.122.211.103:56397] AH01071: Got error 'PHP message: PHP Fatal error: Allowed memory size of 419430400 bytes exhausted (tried to allocate 536870920 bytes) in /var/www/virtual/tourneo-forum.de/htdocs/cms/lib/util/CronjobUtil.class.php on line 518\n', referer: https://tourneo-forum.de/gallery/image-list/
Ich habe den erlaubten Speicher bei Dir mal erhöht.
Bitte die nächsten Tage mal anschauen ob es jetzt klappt.
Gruß
Viktor
Das gilt für deinen Webhoster, der Log gehört aber nicht zum WSC und kann dementsprechend von Fall zu Fall wo anders zu finden sein.
Das gilt für deinen Webhoster, der Log gehört aber nicht zum WSC und kann dementsprechend von Fall zu Fall wo anders zu finden sein.
Hallo,
bei mir gibt es ein Verzeichnis /logs da ist alles drin.
Ich habe ihm jetzt schon 2GB Arbeitsspeicher zugewiesen und der bricht immer noch ab.
Quote[Mon Sep 03 21:19:49.461888 2018] [proxy_fcgi:error] [pid 12814:tid 140240480106240] [client 93.203.187.201:55563] AH01071: Got error 'PHP message: PHP Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 2147483656 bytes) in /var/www/virtual/tourneo-forum.de/htdocs/cms/lib/util/CronjobUtil.class.php on line 518\n', referer: https://tourneo-forum.de/forum/thread/1…ensator-defekt/
Wie viel Arbeitsspeicher bracht der CronJob ??????
Das ist einfach zu viel da müsst Woltlab noch mal schauen.
Da muss man zwischendurch mal den Arbeitsspeicher wieder frei geben.
Gruß
Viktor
Wie viel Arbeitsspeicher bracht der CronJob ??????
Da sind eine ganze Menge fremder Cronjobs installiert, das macht es sehr schwer, die exakte Ursache einzugrenzen. Sieht für mich auch eher nach einer Endlosschleife aus, da würde ein beliebiges erhöhen des Limits auch nicht viel dran ändern.
Ich habe nur den Community Bot 3 von UdoZ installiert und ihn als erstes gefragt ob es an seinem Programm liegt.
Aber wie gesagt bist vor dem Core Upadte auf 3.1.5 pl 1 lief alles ganz normal
Hallo,
ich würde die Cronjobs mal im ACP deaktivieren und dann eine nach dem anderen einschalten.
So sieht man vielleicht welcher Cronjob Probleme macht.
Gruß
Viktor
Das Problem wurde durch einen fehlerhaften Cronjob verursacht, dessen Ausführungszeitpunkt eine unendliche Range zur Folge hatte:
Das Problem ist hierbei die Angabe */0 für die minütliche Ausführung, durch die unendlich viele Werte erzeugt werden und PHP irgendwann der Arbeitsspeicher ausgeht. Wenn eine Ausführung unabhängig der Minute gewünscht ist, so sollte lediglich * verwendet werden, dies entspricht dann "dem nächstmöglichen Zeitpunkt".
UdoZ Ich vermute hier eine manuelle Bearbeitung des Cronjobs, dennoch prüfe bitte, ob dies nicht doch in dein Plugin hineingerutscht ist.
Viktor Das Speicherlimit kann wieder auf einen "sinnvollen" Wert reduziert werden. Sollen eigentlich so unendlich viele Logs aufbewahrt werden, logrotate kann alte Logs auch automatisch löschen
Ich vermute hier eine manuelle Bearbeitung des Cronjobs, dennoch prüfe bitte, ob dies nicht doch in dein Plugin hineingerutscht ist.
Korrekt, jemand hat den Cronjob manuell bearbeitet. Nach Installation läuft er alle 30 Minuten.
Die Änderung auf */0 ist über das ACP möglich. Es wäre also keine schlechte Idee, diese Fehlkonfiguration in CronjobUtil abzufangen.
Es wäre also keine schlechte Idee, diese Fehlkonfiguration in CronjobUtil abzufangen.
Ich gebe dir Recht, denke aber eher, dass es einfach zu * umgeschrieben werden sollte.
Don’t have an account yet? Register yourself now and be a part of our community!