Cronjob Bug?

Shopware 5 Administration
1

Hallo, mir ist aufgefallen, das der Cronjob in Shopware 5 keine “selfrun” Sperre hat. Ich lasse diesen in 10min Abstand laufen und trotz das er schon aktiv ist, wird er wieder ausgeführt. Was zu einer sehr hohen Serverauslastung führt. Womit könnte das zusammen hängen?

2

Das ist normal und ok. Gerade laufende Prozesse werden jedoch nicht erneut aufgerufen, sondern frühestens 10 Minuten nach deren Beendigung. Viele Grüße

3

Problem gefunden. Es liegt daran, das hier sehr viele Kategoriendaten und Artikeldaten vorhanden sind. bzw. der Cache immer wieder neu aufgebaut wird. Sprich der wird nicht in 10 min. fertig und fängt dann einfach einen weiteren Job an, da in der Datenbank das Datum nicht gesetzt wurde. So gesehen ist es schon etwas negativ. Sollte man hier über eine Funktion Nachdenken, die das erneute ausführen blockiert, wenn der Job bereits läuft? Lässt sich relativ simpel umsetzen. $lockfile = \_\_DIR\_\_ .'/runs/cron\_running'; if(!file\_exists($lockfile)) { touch($lockfile); } if($lockFileHandle = fopen($lockfile, "w+")) { if(!flock($lockFileHandle, LOCK\_EX | LOCK\_NB)) { cli\_console("Cron script is still running (exit)", 'info'); exit(); } } else { cli\_console("Lockdatei kann nicht gesetzt werden.(exit)", 'info'); exit(); } //Aufgabe Anfang... //Aufgabe Ende... unlink($lockfile);

4

[quote=“kadis”]Sollte man hier über eine Funktion Nachdenken, die das erneute ausführen blockiert, wenn der Job bereits läuft? [/quote] Genau so läuft es im standard ab - warum es sich bei dir anders verhält, kann ich dir nicht sagen. Ein cronjob wird auf inaktiv gesetzt, solange er läuft. Viele Grüße

5

[quote=„Aquatuning GmbH“][quote=„kadis“]Sollte man hier über eine Funktion Nachdenken, die das erneute ausführen blockiert, wenn der Job bereits läuft? [/quote] Genau so läuft es im standard ab - warum es sich bei dir anders verhält, kann ich dir nicht sagen. Ein cronjob wird auf inaktiv gesetzt, solange er läuft. Viele Grüße[/quote] Merkwürdig. Dann muss ich hier mal schauen, warum dies hier aus dem Ruder läuft. Danke.

6

Hi, wenn ich das richtig sehe, müsste beim Start des Cronjobs das end Feld auf NULL gesetzt werden und erst beim Ende wieder ein Datum erhalten. Beim Lesen der Cronjobs sollte der CronManager (\Enlight_Components_Cron_Adapter_DBAL) Jobs mit end == NULL ignorieren, von daher ist das doch eigentlich “Locking” für einzelne Jobs? Daniel