Admin worker läuft weiter trotz enable_admin_worker=false

[jstr]

Hallo,

ich habe vorhin in der Testumgebung erfolgreich den Admin worker deaktiviert über einen Eintrag in der config/packages/shopware.yaml (enable_admin_worker=false).

Mache ich das gleiche in der Produktivumgebung, so läuft der Admin-Worker weiter.

Jedenfalls werden weiterhin die requests ans Backend geschickt und z.B. der Export von Kategorien funktioniert nach wie vor, was ja eigentlich nicht sein sollte, solange ich die Worker nicht auf dem Server starte.

Gibt es hier irgendwas zu beachten?

Vielen Dank

[Max_Shop]

Hast du den Cache geleert?

[jstr]

Bisher noch nicht, da es in der Testumgebung bisher so funktionierte. Mache ich jetzt aber mal (dauert hier im Shop immer etwas länger, deshalb hatte ich es vermieden).

[jstr]

Das Löschen des Caches hat nichts geändert, der Admin-Worker läuft immer noch.

[jstr]

Ich habe in der Testumgebung jetzt Folgendes herausgefunden:

Sobald in der .env die Variable APP_ENV auf „prod“ gesetzt ist, lässt sich per shopware.yaml er Admin-Worker nicht mehr umstellen.

Allerdings kann ich unter APP_ENV=„dev“ die Variable enable_admin_worker wie gewünscht setzen und dann wieder auf APP_ENV=„prod“ switchen, dann behält er die Einstellung bei.

Vielleicht ist das ganze auch ein Feature, damit man in Produktion nicht versehentlich die Konfiguration ändert, ich schaue noch mal in die Doku.

Gruß

EDIT: Diese Lösung hat auf dem Produktivserver nicht funktioniert. Lösung siehe unten.

[R4M]

@jstr

Sobald in der .env die Variable APP_ENV auf „prod“ gesetzt ist, lässt sich per shopware.yaml er Admin-Worker nicht mehr umstellen.

Also in meiner Testumgebung geht das auch bei Produktiv.

[jstr]

Hier hatte wohl einer das gleiche Problem:

Einrichtung des CLI Workers statt Admin Workers: shopware.yaml Datei ist jedoch nicht vorhanden?

Danke für die Tipps Hab eine neue angelegt. Der Admin Worker war immer noch aktiv. Hab nun auch die im vendor-Ordner angepasst. Half auch nichts. Sobald man sich im Admin einloggt, ist der Server extrem beschäftigt, ich frage mich was da alles für Messages ständig generiert werden: [Bild]   Jetzt versuch ich mal, den Cache zu löschen. Ev wird ja die shopware.yaml erst dadurch wieder neu eingelesen. Steht zwar in keiner Doku, aber wer weiß.   Wenn die haufenweise Messages dann per Server Wo…

Es hat jemand die Lösung gebracht, ein Plugin zu deaktivieren und wieder zu aktivieren. Hat bei mir auch funktioniert.

[ProjektEM]

Also bei mir funktioniert weder die eine (Cache leeren) noch die andere Lösung (Plugin de-/aktivieren).

SW 6.4.20.1
.env -

APP_ENV=prod

shopware.yaml -

shopware:
    admin_worker:
        enable_admin_worker: false

der Worker startet im Backend kurze Zeit später wieder, sichtbar in den Meldungen.

Muss es eine bestimmte Art Plugin sein das deaktiviert/aktiviert wird?

[R4M]

Die „shopware.yaml“ auch korrekt angelegt und im richtigen Ordner?

[ProjektEM]

Die ist im Ordner: /config/packages/ und heißt ‚shopware.yaml‘

Sie enthält:

# config/packages/shopware.yaml
shopware: 
    admin_worker:
        enable_admin_worker: false

Hm. Ich habe gestern die ‚Tools‘ von Friends of Shopware installiert und die Warteschlange gelöscht, dannach hörten die Meldungen erstmal auf. Heute morgen ist aber schon wieder eine Meldung permanent im Backend: „Erfolg 109360 Seiten verbleibend …“ die sich nur langsam (nach 30 min bei 107260 Seiten) verändert. Was auch immer für ein Erfolg damit gemeint ist … Keine Ahnung - ob das der SpeedFinderExport oder webla.hide_categories (beides Plugins) sind oder doch wieder ein Shopware Worker? Oder ist das der Cache-WarmUp (Crongesteuert) - in den FoS-Tools ist unter Wartschleife die WarmUpMessage mit 10528 (zählt langsam runter, ca. 1 Zähler pro Sekunde) aufgeführt.
In den FoS-Tools sind unter „Geplante Aufgaben“ auch etliche ‚scheduled‘ mit täglicher Ausführung (sollen wohl um 13 Uhr starten - ob das wirklich passiert?):

|Name|Intervall|letzte Ausführung|nächste Ausführung|Status|
|app_delete |86400|20. April 2023 um 13:10|21. April 2023 um 13:05|scheduled |
|app_update |86400|20. April 2023 um 13:10|21. April 2023 um 13:05|scheduled |
|cart.cleanup |86400|20. April 2023 um 13:10|21. April 2023 um 13:10|scheduled |
|delete_newsletter_recipient_task |86400|20. April 2023 um 13:10|21. April 2023 um 13:05|scheduled |
|import_export_file.cleanup |86400|20. April 2023 um 13:10|21. April 2023 um 13:05|scheduled |
|log_entry.cleanup |86400|20. April 2023 um 13:10|21. April 2023 um 13:05|scheduled |
|product_download.media.cleanup |2628000|13. April 2023 um 10:28|13. Mai 2023 um 20:27|scheduled |
|product_export_generate_task |60|21. April 2023 um 01:05|21. April 2023 um 01:05|queued |
|product_keyword_dictionary.cleanup |604800|20. April 2023 um 13:10|27. April 2023 um 10:27|scheduled |
|product_stream.mapping.update |86400|20. April 2023 um 13:10|21. April 2023 um 13:05|scheduled |
|requeue_dead_messages |300|21. April 2023 um 01:05|21. April 2023 um 01:05|queued |
|sales_channel_context.cleanup |86400|20. April 2023 um 13:10|21. April 2023 um 13:10|scheduled |
|shopware.elasticsearch.create.alias |300||21. April 2023 um 08:25|skipped |
|shopware.invalidate_cache |20||21. April 2023 um 08:24|skipped |
|shopware.sitemap_generate |86400|20. April 2023 um 13:10|21. April 2023 um 13:10|scheduled |
|SpeedFinderExport |86400||19. April 2023 um 12:18|running |
|version.cleanup |86400|20. April 2023 um 13:10|21. April 2023 um 13:10|scheduled |
|webla.hide_categories |7200||14. April 2023 um 11:45|running |

Cronjobs sind folgende über Plesk gesetzt:
SW6 Worker Messenger Consume alle 5 Minuten [httpdocs/bin/console messenger:consume --time-limit=300 --memory-limit=1G]
SW6 Worker Sheduled-Task Run alle 5 Minuten [httpdocs/bin/console scheduled-task:run --time-limit=300 --memory-limit=1G]
SW6 Cache Clear täglich um 0:00 Uhr [httpdocs/bin/console cache:clear]
SW6 Cache Warmup täglich um 0:15 Uhr [httpdocs/bin/console http:cache:warm:up]
SW6 Sitemap täglich um 1:00 Uhr [httpdocs/bin/console sitemap:generate]
SW6 Media delete unused täglich um 23:00 Uhr [httpdocs/bin/console media:delete-unused]

Ich gehe davon aus, dass die Cronjobs nicht die Meldungen im Backend auslösen, (aber sicher bin ich mir nicht).
Außerdem sind im Log die ganze Nacht über MemoryFehler aufgelaufen:

21. April 2023 um 03:01:31 request CRITICAL - Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\OutOfMemoryError: „Error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1601536 bytes)“ at /var/www/vhosts[…]/httpdocs/vendor/shopware/core/Framework/Adapter/Cache/CacheValueCompressor.php line 48 {„exception“:„[object] (Symfony\Component\ErrorHandler\Error\OutOfMemoryError(code: 0): Error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1601536 bytes) at /var/www/vhosts[…]/httpdocs/vendor/shopware/core/Framework/Adapter/Cache/CacheValueCompressor.php:48)“}

22. April 2023 um 03:01:31 php CRITICAL - Fatal Error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1601536 bytes) {„exception“:„[object] (Symfony\Component\ErrorHandler\Error\OutOfMemoryError(code: 0): Error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1601536 bytes) at /var/www/vhosts[…]/httpdocs/vendor/shopware/core/Framework/Adapter/Cache/CacheValueCompressor.php:48)“} usw.

Diese Fehler scheinen wohl aufgrund der Memorybegrenzung der Worker aufzuschlagen … ich ging eigentlich davon aus, dass 1G eigentlich großzügig bemessen wäre. Der Testshop hat etwa siebzigausend aktive Artikel.

Bin nachwievor etwas planlos.

[concept24]

den Admin-Worker erfolgreich deaktiviert, aber es funktioniert der Import/Export nicht mehr. Hat jemand die gleiche Erfahrung gemacht und eventuell eine Lösung?

[Max_Shop]

Hast du anstelle des Admin-Workers Cronjobs eingerichtet?

[ergobasis]

@ProjektEM

config/packages/shopware.yaml

schon mal mit ordner config/packages/prod/shopware.yaml probiert?

[concept24]

Admin-Worker deaktiviert, Cronjobs eingerichtet
config/packages/prod/shopware.yaml - gerade probiert ohne Erfolg
Import läuft aber auch nicht mit Admin-Worker aktiv

[Lisa_La]

Hast du hierzu eine Lösung gefunden? Wir haben aktuell das gleiche Problem… Cronjobs sind laut unserem Hoster korrekt angelegt.
Allerdings erscheinen in den Mitteilungen seit Tagen die Meldungen:
Erfolg
6010 Seiten verbleibend…
und
Kategorie-Indxierung
Circa 150 Kategorien verbleibend…
Beides wird allerdings nicht weniger.

Der Import funktioniert. Der Export bleibt allerdings beim Status Verarbeite … hängen.

Wenn ich den admin_worker auf true stelle, dann funktioniert übrigens der Export auch wieder.

[ProjektEM]

Also wir haben die shopware yaml zusätzlich in config/packages/prod/ gelegt. und die Warteliste per Froschtool zurückgesetzt. MessengerWorker und SheduledTaskRun laufen per Cron weiter und werden alle 5 Minuten per Corn neu gestartet:

[httpdocs/test..de/bin/console scheduled-task:run --time-limit=300 --memory-limit=512M]
[httpdocs/test..de/bin/console messenger:consume --time-limit=300 --memory-limit=512M]

Das wollen wir noch auf CLI-Service anstelle von Cron umstellen, bei einem Shop haben wir das schon, ist aber noch im Test ob das besser läuft (hängengeblieben Crons bleiben angeblich trotz dem time-limit aktiv, im CLI-Service wohl nicht)

Exportprobleme über die Exportschnittstelle (XML) im Zusammenhang mit Suche-Plugins externer Suchdienstleister gab es bei uns nur, solange in den Artikelbezeichnungen nicht-XML-konforme Zeichen (Steuerzeichen, Ligaturen) enthalten waren.

[tomtomd]

Ich habe das gleiche Problem und bekomme es leider mit keinem der Vorschläge gelöst. Was ich schon probiert habe ist:

• APP_ENV auf dev wechseln und Wert umstellen => klappt nicht, nicht mal auf dev
• shopware.yaml auch in config/packages/prod ablegen => klappt nicht
• Plugin deaktivieren und aktivieren => klappt nicht

Natürlich immer alles schön mit Cache dazwischen leeren.

Weiß hier jemand was? Danke!