Cronjob einrichten... ich verstehe es einfach nicht

Ich habe jetzt schon viele Anleitungen gelesen, aber ich habe das Gefühl ich bin jetzt dümmer.

Der Admin-Worker ist ausgeschaltet in ./config/packages/z-shopware.yaml

shopware:
    admin_worker:
       enable_admin_worker: false

Dann lege ich eine Bash-Script Datei an:

#!/bin/bash
env -i /usr/bin/php83 -f ./../shop/bin/console messenger:consume failed async low_priority --time-limit=300 --memory-limit=512M


env -i /usr/bin/php83 -f ./../shop/bin/console scheduled-task:run --time-limit=300 --memory-limit=512M

Das blockiert mir dann meine Console für 5 Minuten ich erhalte diese Ausgabe:

 [OK] Consuming messages from transports "failed, async, low_priority".

 // The worker will automatically exit once it has exceeded 512M of memory, been running for 300s or received a stop
 // signal via the messenger:stop-workers command.

 // Quit the worker with CONTROL-C.

Scheduled task runner stopped due to time limit of 300s reached

Welchen Teil habe ich hier übersehen? Wo stelle ich ein wann der Job ausgeführt werden soll?

Wie lasse ich spezielle Cronjobs laufen? z.B.

php bin/console product-export:generate 01927c23ec3570e1b8784c2a4d551bfc 0192dc4331ef729a89a28cba8c136e62

Alles in eine PHP-Datei schmeissen und von extern(all-inkl) aufrufen lassen?

Danke und Gruss

Welchen Host nutzt du?

Business und ManagedServer

Wie benutzen 3 Einträge und das läuft ziemlich gut (bezogen auf SW 6.6.x):

bin/console messenger:consume async low_priority --time-limit=55 --memory-limit=512M
bin/console scheduled-task:run --time-limit=55 --memory-limit=512M
bin/console messenger:consume failed --time-limit=55 --memory-limit=512M
1 „Gefällt mir“

In welchem Zeitlichen Abstand? 5 min?

Du hast anscheinend den Unterschied zwischen Befehl und Cronjob verstanden. Ein Befehl wird in der CLI ausgeführt. Ein Cronjob ist ein Programm, dass nach zeitlichen Mustern Befehle ausführt.

Falls du einen eigenen Server hast, kannst du bspw. per crontab -e die Cronjobs für deinen Benutzer öffnen. Solche Rechte hast du bei Managed Servern in der Regel aber nicht, daher gibt es Anleitungen, wie schon hier im Forum verlinkt.

Das --time-limit ist dafür da, dass der Befehl nicht unendlich läuft und nach x Sekunden beendet wird. Je nachdem in welchem Minutentakt der Cronjob den Befehl aufruft, desto niedriger/höher musst du --time-limit setzen. Achte aber darauf, dass --time-limit den Befehl nicht abbricht, sondern ein „Beende die Ausführung am nächstmöglichen Zeitpunkt“ sendet. Daher würde es bei --time-limit=60 und Cronjob jede Minute zu Überschneidungen kommen, was deinen RAM des Servers komplett aufbrauchen kann. Um das zu verhindern gibt es weitere Programme, siehe FAQ.

1 „Gefällt mir“
1 „Gefällt mir“

ok, wenn du es nicht hinkriegst, machen wir es gerade zusammen, geht bei all-inkl. ganz gut.

Nein, in Minutentakt. Hört sich zwar brutal an, aber war im umfangreichen Tests die beste Lösung. Auch bei extrem großen Shops.

1. <?php
2. [exec](http://www.php.net/exec)("/usr/bin/php82 /www/htdocs/KUNDE/pfad/zu/shopware/bin/console messenger:consume failed async low_priority --time-limit=55 -vv 2>&1", $out, $result);
3. echo "Returncode: " .$result ."<br>";
4. echo "Ausgabe des Scripts: " ."<br>";
5. echo "<pre>"; [print_r](http://www.php.net/print_r)($out);
6. ?>
1. <?php
2. [exec](http://www.php.net/exec)("/usr/bin/php82 /www/htdocs/KUNDE/pfad/zu/shopware/bin/console scheduled-task:run --time-limit=55 2>&1", $out, $result);
3. echo "Returncode: " .$result ."<br>";
4. echo "Ausgabe des Scripts: " ."<br>";
5. echo "<pre>"; [print_r](http://www.php.net/print_r)($out);
6. ?>

Jeweils als PHP Datei abspeichern. Ggf. die PHP Version anpassen.
Im KAS - > Tools - > Cronjobs
Beide PHP Dateien minütlich abrufen lassen.

Habe das wie in der eingangs erwähnten Bash am Laufen.
Nur getrennt in 2 Files:
messenger_consume.sh
und
scheduled_task_run.sh

Die werden dann per Cron alle 5 min. aufgerufen.
Die Aufrufe sollten sich halt zeitlich nicht überschneiden.

Denke die Lösung ist besser als über PHP public. Denn die kann theoretisch ohne extra Schutz jeder von außen aufrufen. Die Bash Scripte kannst du außerhab der Web root ablegen.

Viele Grüße
Michael

  1. bei all inkl gibt es keinen cron für shell
  2. kann man den Aufruf durch böse dritte, die den Ort und Namen der Datei ja kennen müssten, durch ein Geheimnis als Parameter schützen.

kann man so aber auch im anderen verlinkten Thema entnehmen.

OK, wenn man keine andere Wahl hat, dann muss das wohl so.

Gibt sicher ein paar Schutzmechanismen wie z.B. IP Check des Aufrufs oder htaccess, etc.
Auf einen reinen Namen, der nicht bekannt ist, würde ich mich nicht verlassen.

Nur falls das auch andere lesen, hat man die Möglichkeit über Bash oder direktem CLI call, dann besser immer den Weg wählen als die PHP Lösung.

Bei 5 Minuten lief die Queue schnell voll, bei 1min immer noch langsam.

Spricht was gegen diese Lösung?

1 1,7,13,19 * * * /bin/console messenger:consume async
59 0,6,12,18 * * * /bin/console messenger:stop-workers
5 * * * * /bin/console scheduled-task:run --time-limit=55 --memory-limit=512M

Scheint mir bisher problemlos

In der Shopware Doku stehen Beispiele. Also ICH würde die Cronjobs so nicht einstellen. Schon gar nicht ohne Parameter.

Mir scheint, dass du nicht wirklich verstehst wie das ganze Funktioniert.

Mit dem Interval * * * * * gibst du an, wie häufig der Cronjob ausgeführt werden soll. So jede Minute. Mit --time-limit=55 gibst du an, dass der Befehl 55 Sekunden lang laufen soll.

Somit ergibt sich, dass der Befehl mindestens 55 von 60 Sekunden (90% der Zeit) lang laufen würde.

Was du da als Idee hattest, macht überhaupt kein Sinn.

Falls 90% der Zeit nicht ausreichen, dann benötigst du einen zweiten Worker/Cronjob. Dafür sind dann Cronjobs aber nicht mehr sehr gut geeignet. Das kannst du dann aber alles in der Entwickler Dokumentation nachlesen.

Warum macht das keinen Sinn? Ohne Zeitlimit läuft der asynchron für knapp 6 Stunden und ich habe Null Probleme bisher.

Die Queue bleibt sauber, im Gegensatz zu den 1 und 5 Minuten Intervallen (warum auch immer).

Die 6 Stunden sind ziemlich beliebig, würde mit 1h oder 24h wahrscheinlich auch gehen. Lasttechnisch tut sich in keinem Fall was.

Wenn der Cronjob einen Fehler wirft, was durchaus passieren kann, dann läuft er ggf. für 5 Stunden überhaupt nicht mehr, bis er erneut aufgerufen wird.

Das ist ein Punkt - ist aber noch nicht passiert.

Und bisher hat das langsame Volllaufen der Queue über Wochen noch keine kritischen Fehler verursacht. Im schlimmsten Fall würden ein paar Stunden ein paar Sachen nicht updaten.

Ich beobachte weiter, kann ich immer noch auf eine Stunde umbauen.