Ideen für Debuggig gesucht: Server hängt nach checkout_process

[hbauer]

Ich bin auf der Suche nach Ideen wie ich die folgende Situation debuggen kann.

Shop:  v2.0.4.2 rev 11374 dated: 2018-07-23
Problem: Checkout hängt häufig im Step checkout_process

Weitere Hintergrundinformationen:
- Zeitraum: vermutlich seit ein paar Wochen
- keine Fehler im shop log
- Server ist ansonsten schnell
- keine erkennbaren Fehler im werbserver log
- selbst gehosted Server
- Serverauslastung: sehr niedrig
-  php 7.2.33-1+0~20200807.47+debian9~1.gbpcb3068
-  Apache/2.4.25 (Debian)

Ich bin mir über den letzten Zeitraum über keine relevanten Änderungen im Shop bewusst. Der Server hat eine IPV6 Adresse erhalten die aber für den Shop Server noch nicht eingetragen ist. Sollte also nicht relevant sein.

Hat jemand Ideen wo ich schauen könnte?

Linkback: https://www.modified-shop.org/forum/index.php?topic=41317.0

[kulli]

Zuerst würde ich mal in der Browser-Konsole schauen was da so ausgegeben wird.
Chrome/Firefox/Edge: - F12

[hbauer]

hm. da gibt es zwar einen Fehler für ein unexecpted token den ich mir mal ansehen werden. Der ist aber in einem js script das im checkout nicht verwendet wird.

Der Post wird ja auch an den Server abgesetzt und geht auch meistens gut durch.

Aktuell glaube ich eher an ein Backendproblem

[Timm]

Moin

Hatte ich am 21.8. auch mindestens einmal. In den Logs der letzten Tage kam es nicht mehr vor.

Bei mir wurde der checkout normal durchlaufen und nach der checkout_confirmation ein POST checkout_process aufgerufen und danach passierte nichts mehr durch die IP des Kunden.

Normalerweise kommt nach einem POST checkout_process wenn er nach der checkout_confirmation passiert, entweder gleich ein checkout_success bei Vorkasse, oder die Weiterleitung zu Paypal welche mit GET checkout_process gefolgt von checkout_success nach Rückleitung abgeschlossen wird. Bei Paypal werden zwischen POST und GET checkout_process noch ne Menge an Shopbilern geladen. Unter anderem das hinterlegte Shoplogo, dass auf der Paypalseite erscheint und im Paypal Profil im Shopbackend hinterlegt ist.

Wenn das POST checkout_process nach der shopping_cart.php aufgerufen wird, dann müsste ein callback/paypal.... passieren, da es sich um PayPal Express handelt.

Bei Amazon Pay gibt es keine checkout_process.

Dadurch könntest du auf die Zahlungsart kommen und vielleicht passiert es immer bei der gleichen.

Gründe dafür, dass nach POST checkout_process nichts mehr passiert wenn der Kunde zu Paypal weitergeleitet wird, könnten sein:

-Internetverbindung bricht ab
-Kunde hat sein Paypal Passwort nicht zur Hand und schließt das Fenster einfach oder macht einfach nicht weiter
-Kunde schließt das Browserfenster vor Weiterleitung zu Paypal weil er denkt der Kauf ist abgeschlossen nach Klick auf kaufen Button
-Browserplugin verhindert Weiterleitung zu Paypal

Wenn es sich um Paypal handelt, könnte man im Paypal Log schauen, ob es andere als 200 und 201 Codes gibt.

Gruss Timm

[hbauer]

Danke für die Hinweise. Leider tritt der Fehler unabhängig von der Zahlungsweise auf, auch bei Vorkasse

[Timm]

Moin

Woher weißt du, dass es sich auch um Vorkasse handelt? Kannst du den Fehler selbst  reproduzieren?

Wenn du nur nach den Serverlogs guckst, dann kann man meiner Meinung nach eigentlich nicht sehen, ob es sich um Vorkasse oder Paypal (ausgenommen Express) handelt. Im Paypal Log wird in beide Fällen ein Eintrag im Paypal Log geschrieben, sobald sich der Kunde auf der checkout_payment befindet. Lass mich aber gerne aufklären, dann kann ich bei mir nochmal näher schauen an besagtem Tag. Ich hatte eigentlich eher auf Paypal getippt, da ich auch in der Zeit ungewöhnlich viele Vorkassezahlungen hatte. Kann aber auch Zufall sein.

Bei mir auch Shopversion 2.0.4.2 aber mit PHP 7.1.33 und nginx als reverse proxy vor dem apache. Paypal Version 1.48.

Gruss Timm

[hbauer]

Ja, heute morgen konnte ich den Fehler mit Vorkasse reproduzieren. Deswegen kann ich auch die logfiles genau zuordnen.

Interessanter Weise wird die Bestellung in die DB geschrieben. Dann hakt es aber irgendwo. Das führt einige Male zu doppelten Bestellungen wenn der Kunde reloaded

[hbauer]

so. kurzes update. Ich hangele mich jetzt in der checkout_process mit debug meldungen bis an die Stelle wo es zu hänngen scheint.

Code: PHP  [Auswählen]

$log->logfile($timestamp."bis hier hin alles ok:schrittname");

Es scheint so zu sein das beim Mail-versandt etwas hängt. Es geht fasst immer flüssig bin

Code: PHP  [Auswählen]

 $payment_modules->before_send_order();
 

Dann scheint es beim sendorder zu hängen.

Code: PHP  [Auswählen]

  include ('send_order.php');

Da werde ich im laufe des Tages mal reinschauen. Aber einen Verdacht habe ich schon (maileinstellungen ipv6)

[hbauer]

Also die Ursache scheint gefunden zu sein. Werde das aber noch etwas beobachten müssen.

Wenn es das ist dann war es eine notwendige Konfigurationsänderung im Spamfilter Rspamd aufgrund der Einrichtung von ipv6. Der führte zu einem Timeout beim Mailversand.

Wenn es das war werde ich die Lösung posten

[hbauer]

So ein paar Tage später erkläre ich das Problem für mich gelöst. Es tritt nur auf für Shopbetreiber, die einen eigenen Server mit Rspamd als Spamfilter verwenden https://www.hagen-bauer.de/2020/09/timeouts-bei-mail-nach-ipv6.html