Running weekly cron jobs … alle paar Minuten!

[truni]

Hallo miteinander, auf einer älteren Installation (TL 2.6.7) habe ich im System-Log Tausende Einträge: alle paar Minuten Generated sitemap "sitemap_de.xml" … und Running weekly cron jobs …

Das müllt die Datenbank ziemlich voll und verursacht Last. Ist dieses Problem «einfach behoben» mit einem TL Update auf die aktuelle 2.7.x Version? Da es eine sensible Site ist, die einigen Traffic hat im Moment, haben wir bewusst auf das Update verzichtet (Bugfixes danach im laufenden Betrieb sind nicht der Hammer) …

Danke für ein paar Tipps!

[Nina]

Wenn es eine "sensible" Website ist, würde ich davon eine Kopie ziehen und unter einer Subdomain parallel zur Live-Website das Update machen. Es gibt auch ein paar kleine Änderungen am Layout die dadurch notwendig werden und bei den Extensions ebenso.

Mit dem Wechsel von 2.6 auf 2.7 hat sich schon eine ganze Menge getan. Ich hatte damals auch das Gefühl, dass das System schneller und stabiler wurde. Hier findest du auf jeden Fall das Changelog.

[truni]

Wenn es eine "sensible" Website ist, würde ich davon eine Kopie ziehen und unter einer Subdomain parallel zur Live-Website das Update machen. .

Danke für den Tipp mit der Subdomain. Nur, wie ist am Besten vorzugehen … z.B. mit der Backup-Extension ein Template erstellen, Neuinstallation auf der Subdomain, tl_files und Co. kopieren und Template reinmachen? Nur: dann kann das das Template nicht mehr eingelesen werden der Backup-Extension (da bereits eine neue Installation) …?

[david.uhlig]

Das hört sich fast danach an als hätte TL keinen Zugriff auf die localconfig.php.

Verwendest du den Safe Mode Hack?
Falls ja dann überprüfe mal direkt in der localconfig.php ob dieser nicht mal kurzfristig deaktiviert wurde. Dafür reicht sogar schon ein Klick in die Checkbox. TL ändert dann sofort den Wert in der Config. Dadurch ist ein Reaktivieren des SMH über das Interface dann nicht mehr möglich (SMH ist ja deaktiviert).
Der Parameter nach dem du ausschau halten solltest ist:

$GLOBALS['TL_CONFIG']['useFTP']

er sollte auf true stehen.

[truni]

… das könnte ein Lösungsansatz sein, jawohl. Unter den Einstellungen konnte ich keine Änderung mehr vornehmen, die Datei localconfig.php habe ich nach einem Backup kurzerhand gelöscht und ersetzt auf dem Webspace. Jetzt siehts besser aus mit den Rechten. Die Logs sind bisher wieder Clean …

[Kahmoon]

Das Problem hatte ich auch schon. Check mal die Dateirechte der localconfig.php und der config.php. Diese müssen 666 sein, damit ein Timestamp bei einer Cronvariable geschrieben werden kann.

[leo]

Bei Problemen mit Dateizugriffsrechten sollte man immer den Safe Mode Hack verwenden und niemals an den Dateirechten schrauben!

https://contao.org/den-safe-mode-hac...le-permissions

[truni]

Der Safe-Mode-Hack ist auch im Einsatz.
Interessanterweise beobachten wir dennoch Dateirechtsprobleme im Schnitt nach mehreren Monaten – plötzlich geht ein Autoupdate nicht mehr des System, weil diverse Dateien keine Schreibrechte mehr haben (z.B. localconfig.php)

… dafür hatte ich bisher keine Lösung ausser einem manuellen Update. Überschreiben solcher Dateien ging auch nicht, nur das löschen und uploaden gelang bisher.

Dünkt mich höchst eigenartig, dass ich eine Installation über Zeit verändert in den Rechten. Trotz schon seit Anfang aktivem Safe-Mode-Hack.

[Kahmoon]

Dito. Bei mir ist auch der Safe-Mode-Hack im Einsatz. Passierte trotzdem. Weiß nicht ob mein Vorschlag dein Problem löst. Bei mir hat es das.

[andreas.schempp]

Am besten auf die neuste Version aktualisieren, da funktioniert der SMH meinem Wissen nach besser.

[jogoto]

Ich habe aktuell dasselbe Problem unter contao 2.11.11
Die Abstände, in denen die weekly cron jobs ausgeführt werden variieren zwischen 5 und 24 Minuten. Es wird jedes mal eine neue Sitemap und die CSS Dateien angelegt.

SMH ist im Einsatz und funktioniert, localconfig.php hat die richtigen Rechte und lässt sich beschreiben.

Was könnte es also noch sein?

[BugBuster]

Der Eigentümer der localconfig stimmt auch?
Je nach Rechten reicht das eventuell nicht.
Probier mal als Test per ftp mit den selben Daten dich zu connecten und eine dummy Datei in das Verzeichnis config zu kopieren.
bzw. was sagt der Contao Check?

[jogoto]

Sorry, mit "Rechte" meinte ich Eigentümer, Gruppe und Berechtigungen. Stimmen alle, FTP ist problemlos möglich und ich arbeite gerade täglich damit.

Contao Check sagt, dass
- contao/preview.php fehlt (Absicht / umbenannt)
- alle tl_files/music_academy/ fehlen (Absicht / nerven mich / gelöscht)
- system/modules/calendar/Events.php corrupt ist (ergänzt)

[do_while]

Hallo jogoto,

um die Schreibrechte aus der Sicht von Contao zu testen, kannst Du einfach einen Parameter in System-Einstellungen ändern, z.B. bei "Leere URLs nicht umleiten" den Haken setzen und speichern. Ist der Haken noch gesetzt, wenn Du wieder in die Einstellungen hinein gehst?
Diese Einstellungen werden nämlich auch in der localconfig.php gespeichert. Wird der Haken gespeichert, so sind auch die Schreibrechte korrekt und Du musst eine andere Ursache suchen.

[jogoto]

Ja, Änderungen in den Einstellungen werden gespeichert, Haken bleibt.

Was mir in diesem Zusammenhang auffällt: in den Logs wird die Änderung in den Einstellungen vermerkt. Gerade beim rückgängig machen also

The global configuration variable "doNotRedirectEmpty" has been changed from "true" to ""

Zusätzlich entstehen bei jeder Änderung in den Einstellungen noch

The global configuration variable "defaultUser" has been changed from "1" to "1"

und

The global configuration variable "defaultGroup" has been changed from "1" to "1"

Ist das normal?

[jogoto]

Ist das normal?

Scheint normal zu sein, zumindest hab ich das bei anderen 2.11.11 Installationen auch.


Was aber fehlt ist der Eintrag

Weekly cron jobs complete

contao scheint also tatsächlich den cri job nicht zu Ende zu bringen.

Die Einträge in der localconfig lauten:

$GLOBALS['TL_CONFIG']['cron_weekly'] = 201309;
$GLOBALS['TL_CONFIG']['cron_daily'] = 20130303;
$GLOBALS['TL_CONFIG']['cron_monthly'] = 201306; 

[do_while]

Es könnte ja sein, dass der Cron-Job mit Fehler abbricht oder abstürzt und dann kommt der Corn nicht dazu, seine Zeit einzutragen.

Jede Erweiterung hat die Möglichkeit, sich für einen Cronaufruf zu registrieren.
Du könntest also in allen Module in system/modules/.../config/config.php nachsehen, ob eine Cronregistrierung eingetragen ist:
$GLOBALS['TL_CRON']['monthly'][] = ...
$GLOBALS['TL_CRON']['weekly'][] = ...
$GLOBALS['TL_CRON']['daily'][] = ...
$GLOBALS['TL_CRON']['hourly'][] = ...

Dann kannst Du ausprobieren, die entsprechende(n) Erweiterung testweise zu deaktivieren.
Kontrolle, ob dann der Cron seine Zeiten korrigiert.

[jogoto]

Danke, danke, danke!

Das war die richtige Spur. Außer den contao eigenen Modulen gab es nur eines mit einem Weekly cron job:

mb_richMedia

$GLOBALS['TL_CRON']['weekly'][] = array(
	'MbRichMedia',
	'cleanTable'
);

Erweiterung gelöscht und siehe da: Weekly cron jobs complete