Nach update auf 6.4.1 kein Mailversand mehr an Kunden

Ich gehe über einen SMTP Server und habe immer noch keine Problemlösung in Sicht. Ich habe mir auch alle Events angeschaut - scheinen alle korrekt hinterlegt zu sein. Das komische ist, das ich auch keine Testmail bei den E-Mailvorlagen verschickt bekomme. Die Mitteilung: „Die Test-Mail ist erfolgreich versandt worden.“ erscheint, aber es kommt keine Mail bei mir an…ich bin voll am verzweifeln !

Noch jemand kreaktive Ideen ?? Vielleicht jmd. vom Shopware 6 Support eine Idee ?

@mr.unschuldig
Habe jetzt einen Cronjob angelegt mit bin/console messenger:consume
und es klappt nicht - keine Mails - keine Fehlermeldung

@piratenkiste

Gemäß Deiner Angabe, dass nicht mal die Testmail raus geht, sind wir noch ein Schritt vor dem eventuellen Workaround mit Cronjob.

Konkret daher nun die Frage:

Was sagen die Logdateien, in Zuge einer Testemail?
Insbesondere Log Webserver und Mailserver. Da sollte dann definitiv was zu sehen sein.

Uff da erwischt du mich total …davon habe ich null Ahnung:-) @mr.unschuldig :grinning_face_with_smiling_eyes:

In var/log ist die letzte prod…datei vom 26.5…daher nehme ich mal an, dass es da zu einem schwerwiegendem Problem innerhalb SW gekommen ist und daher der Eintrag erfolgt ist.
Das Zustellen der Mails wird wohl nicht als schwerwiegend erfasst.

Kann es sein, dass ich in meinem Hauptverzeichnis die .env auf APP_ENV=dev stellen muss, um eine Fehlermeldung wegen der Mails zu erreichen ?

Mailserver ist von Seiten meines Hosters alles prima eingestellt

@piratenkiste

Gemeint waren schon grundlegend die Logdateien vom Server, nicht von Shopware. Anhand derer kann man recht gut nachvollziehen, was da vor sich geht und wo es evtl. zu Problemen kommt.

@mr.unschuldig
Danke …ich habe mal eine Kontaktanfrage über meinen Shop gesendet und folgende Fehlermeldung in der Log erhalten (meine Hoster habe ich mit XXX ersetzt)

2021/06/01 18:55:57 [error] 10744#10744: *934596 FastCGI sent in stderr: „PHP message: PHP Fatal error: Shopware\Core\Framework\MessageQueue\Handler\RetryMessageHandler::handle(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition „SwagMigrationAssistant\Migration\MessageQueue\Message\ProcessMediaMessage“ of the object you are trying to operate on was loaded before unserialize() gets called or provide an autoloader to load the class definition in /var/www/clients/client2555/web11514/web/vendor/shopware/core/Framework/MessageQueue/Handler/RetryMessageHandler.php on line 46“ while reading response header from upstream, client: XX.XX.XXX.XXX, server: XXX, request: „POST /api/_action/message-queue/consume HTTP/2.0“, upstream: „fastcgi://unix:/var/lib/php5-fpm/web11514.sock:“, host: „XXX“

Kannst du damit etwas anfangen ?

Line 46 ist lautet:
->search(new Criteria([$message->getDeadMessageId()]),

Die MessageHandler.php sieht folgendermaßen bei mir aus

<?php declare(strict_types=1); namespace Shopware\Core\Framework\MessageQueue\Handler; use Psr\Log\LoggerInterface; use Shopware\Core\Framework\Context; use Shopware\Core\Framework\DataAbstractionLayer\EntityRepositoryInterface; use Shopware\Core\Framework\DataAbstractionLayer\Search\Criteria; use Shopware\Core\Framework\MessageQueue\DeadMessage\DeadMessageEntity; use Shopware\Core\Framework\MessageQueue\Message\RetryMessage; class RetryMessageHandler extends AbstractMessageHandler { /** * @var EntityRepositoryInterface */ private $deadMessageRepository; /** * @var iterable|AbstractMessageHandler[] */ private $handler; /** * @var LoggerInterface */ private $logger; public function __construct( EntityRepositoryInterface $deadMessageRepository, iterable $handler, LoggerInterface $logger ) { $this->deadMessageRepository = $deadMessageRepository; $this->handler = $handler; $this->logger = $logger; } /** * @param RetryMessage $message */ public function handle($message): void { /** @var DeadMessageEntity|null $deadMessage */ $deadMessage = $this->deadMessageRepository ->search(new Criteria([$message->getDeadMessageId()]), Context::createDefaultContext()) ->get($message->getDeadMessageId()); if (!$deadMessage) { return; } $handler = $this->findHandler($deadMessage->getHandlerClass()); if ($handler) { $handler($deadMessage->getOriginalMessage()); } $this->deadMessageRepository->delete([ [ 'id' => $deadMessage->getId(), ], ], Context::createDefaultContext()); } public static function getHandledMessages(): iterable { return [RetryMessage::class]; } private function findHandler(string $handlerClass): ?AbstractMessageHandler { foreach ($this->handler as $handler) { if (\get_class($handler) === $handlerClass) { return $handler; } } $this->logger->warning(sprintf('MessageHandler for class "%s" not found.', $handlerClass)); return null; } }

Kann es sein, dass in der Enqueue Tabelle einen Eintrag gibt, der vom Migrationsassistenten abhängt?
Ist dieser installiert?

Puh, da ist guter Rat teuer.

Ich hänge gerade an einem Teil der Logdatei und frage mich, woher das kommt bzw. ob das seine Richtigkeit hat…

request: „POST /api/_action/message-queue/consume HTTP/2.0“, upstream: „fastcgi://unix:/var/lib/php5-fpm/web11514.sock:“, host: „XXX“

Warum taucht hier ein php5-fpm auf? Irritiert mich ein wenig.

Ansonsten würde ich ggfs. noch gerne wissen, was Du eingestellt hast beim Mailer, insbesondere Port und Verschlüsselungsmethode.

@Marcus_Salden
Hallo, nein der Migrationsassistent ist nicht installiert
Nach welcher Tabelle soll ich denn Ausschau halten ?

@mr.unschuldig

Danke für dein Bemühen ! Als Mailer hab ich den SMTP (Port 587 / TLS)…wurde auch von @TimmeHosting überprüft und arbeitet soweit fehlerfrei. Bei SW6.3 hatte ich den lokalen Mail-Agenten aktiv …habe jetzt aber umgestellt

man kann zB im PHPMyAdmin nach „enqueue“ suchen. Da stehen dann die Messages drin, die abgearbeitet werden. Ich würde mal vermuten, dass hier eine Message drin ist, die den Fehler auswirft. Irgendetwas, was hiermit in Verbindung stehen könnte: „SwagMigrationAssistant\Migration\MessageQueue\Message\ProcessMediaMessage“
Diese Zeilen könnte man aus der Tabelle löschen und prüfen, ob die Verarbeitung dann durchläuft…

Die Zeile SwagMigrationAssistant\Migration\MessageQueue\Message\ProcessMediaMessage gibt es nicht in der Tabelle enqueue

vielleicht mal nach ‚%ProcessMedia%‘ im body-feld suchen

%ProcessMedia%‘ ist nirgends zu finden

gibts da nen eintrag in der tabelle „dead_message“ oder „message_queue_stats“?

Ich habe Hoffnung das wir einen Schritt vorwärts kommen:-)
In beiden Tabellen dead_message und message_queue_stats sind
jeweils die Eintrage SwagMigrationAssistant\Migration\MessageQueue\Message\ProcessMediaMessage
vorhanden.
4 Einträge in der dead_message und 1 Eintrag in der anderen Tabelle

Also zu der Fehlermeldung wegen php5-fpm brauchst du dir nicht mehr den Kopf zu zerbrechen…ich habe vom Hoster folgende Antwort erhalten: „Der Dateipfad in der Fehlermeldung ist hier auch nicht schlimm, dieser ist historisch gewachsen. Alle Sockets der einzelnen Webseiten werden in diesem Verzeichnis abgelegt und der Name beinhaltet hier nur noch PHP5 gibt jedoch keinerlei Auskunft über die PHP Version die wirklich genutzt wird.“
Von daher kannst du dies ignorieren :grinning:

Ich würde hier vermuten, dass ein task, vlt der requeue_dead_messages, versucht, die dead messages wieder auszuführen. Dort befinden sich Einträge des Migrationsassistenten, der aber nicht mehr installiert ist.
Ich kann dir da leider nicht mit Sicherheit sagen, ob man die Einträge in der Dead-Messages Tabelle bedenkenlos löschen kann (soweit ich das sehen kann gibts da nur einen foreign key zu den scheduled tasks). Dafür wäre eine Kopie des Shops in einer Entwicklungsumgebung gut.

Hallo Marcus,

das mit dem Migrationsassistenten konnte ich klären (Einfach nochmal Neuinstallation und danach wieder deinstalliert - hat geklappt)

Wenn ich aber über einen CronJob wieder die Mails einrichte mit bin/console messenger:consume --memory-limit=2048M --time-limit=300 kommt folgende Fehlermeldung:

07:30:05 WARNING [php] User Notice: Key file „file:///var/www/clients/client2555/web11514/web/config/jwt/public.pem“ permissions are not correct, recommend changing to 600 or 660 instead of 644 [„exception“ => ErrorException { …}]

Woran liegt das ?

Super! Dann scheinen die Einträge damit bereinigt worden zu sein :slight_smile:
Die Warnung betrifft die Zugriffsrechte.
In der Konsole kann man die im entsprechenden Ordner anpassen:
chmod 600 public.pem
oder
chmod 660 public.pem