Fehler: Another worker is already running for receiver: "async"

Shopware 6 (German) Allgemein
1

Meine Logfiles (/httpdocs/var/log/prod-2024-01-23.log) sind voll mit immer der gleichen Fehlermeldung:

[2024-01-23T15:14:05.419853+00:00] request.ERROR: Uncaught PHP Exception Shopware\Core\Framework\MessageQueue\MessageQueueException: "Another worker is already running for receiver: "async"" at /var/www/vhosts/meine-domain.at/httpdocs/vendor/shopware/core/Framework/MessageQueue/MessageQueueException.php line 38 {"exception":"[object] (Shopware\\Core\\Framework\\MessageQueue\\MessageQueueException(code: 0): Another worker is already running for receiver: \"async\" at /var/www/vhosts/meine-domain.at/httpdocs/vendor/shopware/core/Framework/MessageQueue/MessageQueueException.php:38)"} []

Hat jemand eine Idee was hier das Problem ist?

2 „Gefällt mir“
2

Haben hier das selbe Problem seit dem Update auf 6.5.8.2 (dabei wurde auch PHP auf 8.2.14 angehoben). Hinzu kam noch, dass Bestellungen nicht ausgeführt wurden, sondern mit der Nachricht „Ihr Warenkorb ist leer“ quittiert wurden. Das ließ sich allerdings erstmal beheben, indem wir unter System->Mailer auf synchronen Mailversand gestellt haben. Hast Du schon eine Lösung gefunden oder jemand anderes eine Idee?

PS. vor dem Update hatten wir in dem Shop unter Nachrichten immer „XXXXX Seiten verbleibend“, wie hier beschrieben https://forum.shopware.com/t/erfolg-200-seiten-verbleibend/98530. Das konnten wir mit dem Plugin „Tools“ und „Warteschlange zurücksetzen“ beheben. Hast Du vielleicht was Ähnliches gemacht?

PPS. Da laut dieses Beitrags https://forum.shopware.com/t/request-failed-with-status-code-500-bei-store-update/102387 eine ähnliche Problematik aufgrund des SW-Plugins „Store“ aufgetreten ist, teste ich jetzt mal, ob das Deaktivieren des Plugins etwas ausmacht.

1 „Gefällt mir“
3

Kurzes Update: Ein paar Tage lief es zunächst problemlos, jetzt war der Fehler wieder da… Irgendwas passt da mit den workern nicht. Möglicherweise hängt es mit dem Plugin Tools von Friends of Shopware oder einfach mit der SW 6.5.8.2 zusammen. Da wird gerade viel zum Thema gepatcht. Ich geh jetzt mal auf 6.5.8.4.

@ mm-webconsulting Setzt ihr das Tools-Plugin auch ein oder sonst schon was rausgefunden?

4

Nein, das Plugin verwenden wir nicht.

Nachdem ich den Mailer auf synchronen Mailversand gestellt habe, kommt bei uns auch keine Fehlermeldung mehr. Unsere Version ist die 6.5.8.2.

5

Super, dass bei Dir keine Meldungen mehr auftauchen. Bei uns war’s das leider nicht abschließend. Es kommen zwar manche Bestellungen durch - heute morgen war der Fehler im Log aber wieder 9mal innerhalb von 3 Minuten drin. Tools- und Store-Plugin waren deaktiviert - SW 6.5.8.4. Bin langsam etwas ratlos…

Hier vielleicht noch ein Ansatz. Mit dem wieder aktivierten Tools-Plugin sehe ich unter „Geplante Aufgaben“ u.A. folgende Tasks:
product_export_generate_task - Intervall: 60 Status: scheduled
shopware.invalidate_cache - Intervall: 20, Status: skipped

Die Intervalle kommen mir recht kurz vor.
Ein passender Forenbeitrag, zu dem es aber anscheinend auch noch keine Lösung gibt:

6

Wie sieht denn euer Cronjob aus?
Ich meine mich zu erinnern, dass der oben beschriebene Fehler aufgehört hat nachdem wir die Cronjobs angepasst haben. Diese hier nutzen wir aktuell, basierend auf der Doku:

MAILTO=""
*/6 * * * * /usr/local/vhosts/WEBSPACE/shopware/bin/console scheduled-task:run --time-limit=300 --memory-limit=512M
*/6 * * * * /usr/local/vhosts/WEBSPACE/shopware/bin/console messenger:consume failed async --time-limit=300

Wichtig ist hierbei das „failed async“, da hatte sich mit Shopware 6.5 was geändert:

2 „Gefällt mir“
7

Wir setzen keine Cronjobs ein. Alles nur über die Standard-(admin?)Worker. Mir ist bewusst, dass das keine best-practice ist, aber normalerweise funktioniert ja auch das - auch async-Mails, ohne dass ein Admin eingeloggt ist.

8

Da ich bislang keine andere Lösung gefunden habe, habe ich jetzt mal die Cronjobs eingerichtet. Hat das eine Bewandtnis, dass beim zweiten Job messenger:consume kein Memory-Limit eingesetzt wird? In der Doku steht außerdem ein Time-Limit von 60. Hab aber auch ein anderes Tutorial gefunden, indem auch die 300 genutzt werden (https://www.atloss.de/ratgeber/shopware-6-cronjob/).

Laufen die beiden Jobs dann bei euch parallel oder alternierend und wie häufig lasst ihr die dann laufen?

9

Bei uns laufen die Cronjobs parallel jede Minute und für 55 Sekunden.
Wichtig wäre noch: Bei Cronjobs muss man die PHP Version und Pfade ansprechen. Das sieht dann so wie folgt aus:

/usr/bin/php8.2 /home/www/shopware6/bin/console messenger:consume failed async --time-limit=55
/usr/bin/php8.2 /home/www/shopware6/bin/console scheduled-task:run --time-limit=55

und denkt daran, der Admin Worker soll über die z-shopware.yaml deaktiviert werden, da die andere Datei bei den Updates überschrieben werden kann.

1 „Gefällt mir“
10

Vielen Dank für die Tipps!
Bei mir siehts jetzt noch etwas anders aus:

/opt/plesk/php/8.2/bin/php /var/www/vhosts/xyz/httpdocs/bin/console scheduled-task:run --time-limit=120 --memory-limit=512M
/opt/plesk/php/8.2/bin/php /var/www/vhosts/xyz/httpdocs/bin/console messenger:consume failed async --time-limit=120 --memory-limit=512M

Und dann alternierend alle 6min. - also mit 3min. Abstand zwischen den beiden mit jeweils ner Minute Pause dazwischen. Bei paralleler Ausführung müsste ja wahrscheinlich das MemoryLimit halbiert werden, wenn der PHP-Interpreter im Hosting max. 512M hat.

Mal schauen, ob die 6min. zu lang sind. Oder hängt da dann doch sowas zeitkritisches dran, dass man das ständig laufen haben sollte? In dem betreffenden Shop kommen in der Regel nicht mehr als 20 Bestellungen am Tag rein.

11

Wir hatten ebenfalls Probleme mit der Message Queue.
Die empfohlenene Einstellungen laut einer Doku haben dazu geführt, dass die Message Queue nicht korrekt abgearbeitet worden ist. Daher haben wir den Cronjob wieder auf unsere 6.4er Variante umgestellt. (Cronjob alle 2 Minuten)
Sichtbar wurde das mit dem „Tools“ Plugin von Friends of Shopware. Mit dem Plugin kann man auf den grünen / roten / orangenen Punkt neben „Administration“ klicken und dann kann man die Details der Message Queue sehen.

echo 'Message Queue abarbeiten...<br>';
//$output = shell_exec('php82 ../../bin/console messenger:consume failed async --time-limit=110 --memory-limit=512M');  // Cronjob 6 min - not working correctly...
$output = shell_exec('php82 ../../bin/console messenger:consume --time-limit=50 --memory-limit=512M async low_priority');  // Cronjob 2 Min - OK
echo "<pre>$output</pre><hr>";

echo 'Scheduled Tasks abarbeiten...<br>';
$output = shell_exec('php82 ../../bin/console scheduled-task:run --time-limit=50 --memory-limit=512M');
echo "<pre>$output</pre><hr>";
12

Eigentlich sollte ja der messenger-task einfach „endless“ im Hintergrund ablaufen.
Dafür würde man das Script einmal starten und dann erst wieder wenn der Rechner neugestartet wird. Oder wenn es Probleme gab (Memory Fehler) oder wenn einer der Task abstürzt.

Wenn man es richtig macht kommt das Ganze in ein supervisord script. Falls das Script abstürzt startet supervisord das einfach wieder neu. Nur oft geht das nicht weil der Hoster nur cron-jobs zulässt.

Dann kommt aber noch der Parameter --time-limit ins Spiel. Die Idee dabei ist, dass das Script z.B. max. 110 Sekunden läuft und sich dann selbst beendet. Der Cron startet dann alle 2 Minuten das Script neu.
Nur gibt es dabei etliche Probleme:

  • Das Beenden passiert nur wenn gerade nichts zu tun ist, sprich läuft gerade ein Script dann wird der Process NICHT beendet.
  • Der Process muss noch in der Lage sein sich selbst zu beenden
  • Restart Zeit und time-limit müssen zueinander passen.

Wenn hier irgendwas schief läuft kommt es zu der Meldung. Ein NEUER Process testet darauf ob ein alter noch läuft und falls ja bleibt der ALTE Process stehen …

Falls jemand Bedarf für ein Beratung oder eine Dienstleistung hier hat, kurz bei mir melden (private).