Wenn Ihr das von mir vorgeschlagene Skript bei euch eingerichtet hättet, würdet Ihr sowohl den Cache nicht deaktivieren müssen - was sowohl von Google als auch von Kunden mindestens genauso schlimm bewertet wird wie der Fehler -, als auch mitbekommen, durch welche Handlungen der Fehler auftritt. Denn das Skript würde euch immer wieder eine E-Mail senden.
Seit dem Update habe ich alles Mögliche unternommen, um diesen Fehler zu reproduzieren, erhalte jedoch keine E-Mails mehr. Auch kommen Bestellungen ganz normal rein, und die betroffene Datei zeigt keinen Eintrag mit der Session.
Eine vollständige Entwarnung bezüglich dieses Problems kann ich jedoch erst übermorgen geben, basierend auf meinen Erfahrungen der letzten vier Wochen.
Das Problem daran ist, dass ich nicht auf die Bash-Script Ebene komme und irgendwelche .sh Dateien anlegen kann, da wir einen managed Server haben und keine Shell Scripte hinzufügen können. (?) (Sorry - kenne mich damit nicht wirklich aus - vermute mal, dass es ein Shell Script oder etwas in der Richtung ist - wüsste auch nicht wo ich die Datei ablegen soll und ob ich Serverseitig überhaupt die Möglichkeit dazu habe zumindest denke ich, dass ich da nichts anlegen kann?! - gib mir ne Windows Batch-Datei - Damit komm ich wohl klar ).
Ich könnte mir vorstellen, dass man es per SSH / Cronjob Script anlegen kann, aber da bin ich ebenfalls raus. Das übersteigt leider meine Kenntnisse in dem Bereich.
Ebenso vermute ich, dass die meisten hier mit dem Code nicht ebenso nicht viel anfangen können.
Daher denke ich, dass es nicht am „wollen“ liegt, sondern eher am „können“.
Btw:
Der SSH Befehl grep -RH 'session-' /www/htdocs/w00xxxxx/sw6shop/var/cache/**/pools/app
hatte vor dem Update 2 Zeilen ausgespuckt. Habe die genaue Angabe aber nicht mehr gespeichert gehabt.
Aktuell wird nichts angezeigt. Ebenso scheint aktuell alles zu funktionieren. Langzeittest-Ergebnisse folgen…
Aktuellstes Update ist bereits aufgespielt. @all: Die Standard-Plugins (siehe meine Screenshots oben) funktionieren alle noch, trotz einiger Warnungen vor möglichen Problemen beim Update.
Moin, das ist nicht cool, dass das Update bei euch nichts gebracht hat. Bei mir läuft alles.
Habt ihr nach dem Update unter " Einstellungen > System > Caches & Indizes" alle Funktionen Ausgeführt? Einfach von oben nach unten, nacheinander durchlaufen.
@XXL-Webdesign grundsätzlich kann ich mir Vorstellen, dass man bash Scripte mit php ansprächen kann. Da bin ich jedoch raus.
Vielleicht kannst du es sogar in PHP schreiben:
Statt Meldung ausgeben einfach etwas ausführen.
Wahrscheinlich kannst du dann auch auf screen verzichten. Und wie gesagt jede Distribution hat seine Eigenarten, welche beachtet werden müssen. NixOS zum Beispiel hat an eine andere Stele den „bin“ Ordner. Das ist jedoch nur für Mailversand notwendig. Man könnte auch eine Art Logdatei lokal ablegen.
ChatGPT hat mal das ausgegeben:
"…
<?php
while (true) {
// Durchsuche die Logdateien nach dem Muster 'session-'
$result = shell_exec("grep -RH 'session-' /srv/www/domain/var/cache/**/pools/app 2>&1");
// Wenn das Muster gefunden wurde
if (!empty($result)) {
// Cache leeren
$cacheClean = shell_exec("sudo -u nginx /srv/www/domain/bin/console cache:clear");
// E-Mail senden
$to = "admin@domain.de";
$subject = "Sitzungsproblem im Shop";
$message = "Dies ist eine Test-E-Mail.\n\n" . $cacheClean;
$headers = "From: system@domain.de";
// E-Mail senden
mail($to, $subject, $message, $headers);
// Breche die Schleife ab
break;
}
// Kurze Pause
sleep(1);
}
?>
Dieses PHP-Skript führt im Wesentlichen die gleichen Aktionen aus wie das ursprüngliche Bash-Skript. Es durchsucht die Logdateien nach dem Muster ‚session-‘, leert den Cache und sendet eine E-Mail, wenn das Muster gefunden wird. Es verwendet die shell_exec-Funktion, um Befehle auszuführen und mail, um E-Mails zu senden. Beachten Sie jedoch, dass die Ausführung von Befehlen über shell_exec potenzielle Sicherheitsrisiken birgt und sorgfältig gehandhabt werden sollte.
…"
Danke, ist bisher nur einmal aufgetreten, ca. 2 Stunden nach Update. Vorher bis zu 30 mal am Tag.
Ist vielleicht jetzt behoben, aber ich lass das Script mal weiter laufen.
@all / nach Update - kurzes Feedback:
Gestern sind wieder 2 Kundenkonten angelegt worden, jedoch keine Bestellung ausgelöst worden.
Verglichen mit dem Problem zuvor, dürfte das Problem weiterhin bestehen.
Allerdings konnte ich gestern nicht den Fehler selber provozieren/nachstellen. Es war aber zuvor auch nicht auf allen Browsern und zu jedem Zeitpunkt nachvollziehbar. Während Firefox / PC kein Problem war, war Safari / iOS ein Problem usw. Zu einem anderen Zeitpunkt war auch Chrome (PC) betroffen… Dies hatte ich allerdings im ersten Schritt leider noch nicht getetstet gehabt.
Fakt ist, zuvor gab es mehr Käufe und die Kundenkonten haben sich nahezu 1:1 mit den Bestellungen gedeckt. Ein Cronjob der alle 30 min den Cache löscht, hat vorgestern zumindest wieder zu einem scheinbar normalen Verhalten geführt, während nach Update und ohne den Cronjob wieder die Käufe ausblieben jedoch Kundenkonten (Gastbestellerkonten) angelegt wurden.
Da ich den Fehler gestern zwar nicht nachstellen konnte, und auch per Konsole der im Iussue Tracker hinterlegte Command Line Befehl weiterhin nichts angezeigt hatte, jedoch das Verhalten der Kunden nach wie vor dafür spricht, dass etwas nicht stimmt, muss ich das ganze intensiver beobachten und vielleicht tiefer graben.
Gibt es eine Möglichkeit, diverse Aktionen/Statusmeldungen zu loggen? Also insbesondere die Ereignisse - „zum Warenkorb hinzugefügt“ und „es befinden sich keine Artikel im Warenkorb“
Notfalls würde auch eine quick’n’dirty Lösung vorerst reichen, wo per PHP eine (Log-)Datei auf dem Server in einem Ordner erstellt wird, in der man nachschauen kann.
Aktuell ist es sogar ausreichend, die Core-Dateien umzuschreiben um ein Logging zu ermöglichen.
(Jegliche Änderungen an Core Dateien protokolliere ich eh schon und überwache die nach jedem Update.)
@I_c_h
Danke. Denke werde das ganze nacher mal anpassen und testen.
Daraus - und mit dem was ich bislang schon gebaut habe (Cron - Cache löschen) sollte sich ein funktionierendes PHP Script bauen lassen. (Ergebnis poste ich später)
Eine kurze Frage dazu hätte ich allerdings noch:
Was genau macht das Script bzw. die grep Zeile? (Mail senden, Cache löschen ist klar…)
Des Weiteren fehlt der letzte Parameter in dem Script im Gegensatz zu dem Bash-Script was du gepostet hast. Darf / muss dieser fehlen, oder hat ChatGPT den entfernt?
Mach dich nicht krank mit dem Shopsystem. Es ist zwar schon traurig von Shopware AG wie die Firma mit dem Thema umgeht oder umgegangen ist, wie zum Beispiel mein erstes Ticket zur dem Thema:
Aber du wirst es leider so nicht ändern können.
‚grep‘ ist ein Befehl, um etwas zu suchen. In diesem Fall sucht es nach einer Datei mit einem Muster ‚session-‘.
Die Umleitung 3>&1 ist wahrscheinlich überflüssig und wurde von GPT entfernt. Ich glaube, dass 1 die normale Ausgabe ist, 2 die Ausgabe von Fehlern und 3 etwas anderes war, bin mir jedoch nicht sicher. Daher habe ich es hinzugefügt.
Des Weiteren hat mir noch ein angehender Entwickler empfohlen, bei PHP nicht mit einem absoluten Pfad in PHP zu arbeiten, sondern diese Funktion zu verwenden.
Seit wir Einstellungen > Warenkorb „Zeit in Minuten, die ein Kunde Zeit hat eine Transaktion abzuschließen“ auf 120 Minuten gestellt haben, haben wir auch keine Probleme mehr mit dem Warenkorb - also seit Dienstag. Habt ihr das schon probiert?
Ich prüfe alle Shops im Moment jeden Tag, jede Stunde, mehrmals.
Gestern Nacht haben wir auch das Update geladen - im Moment funktioniert alles. Wir beobachten weiter.
Hallo I_C_H,
so, gerade wurde Dein Script wieder ausgeführt und der Cache gelöscht. Ich kann aber nicht replizieren, warum …
Oder werden die Sessions auch noch für andere Events benötigt?
VG
So… Hab mich mal ein wenig über das Logging schlau gemacht.
Im Dev-Logging wird nahezu jeder Schritt protokolliert. Incl. welche Regel greift und viele weitere Routinen. Warenkorb Ereignisse inclusive.
Standard gemäß ist dieses Logging nur im Developer Modus verfügbar. Allerdings kann man die grundsätzliche Logging-Routine auch in die Produktivumgebung hinzufügen / ersetzen.
/your-sw6-path/config/packages/prod/monolog.yaml
# /your-sw6-path/config/packages/prod/monolog.yaml
################################# ORI monolog.yaml from SW 6.5.8.7 ###############################################
#monolog:
# handlers:
# main:
# type: fingers_crossed
# action_level: error
# handler: nested
# excluded_http_codes: [404, 405]
# buffer_size: 30 # How many messages should be saved? Prevent memory leaks
# business_event_handler_buffer:
# level: error
# nested:
# type: rotating_file
# path: "%kernel.logs_dir%/%kernel.environment%.log"
# level: error
# console:
# type: console
# process_psr_3_messages: false
# channels: ["!event", "!doctrine"]
#
##################################################################################################################
################################# EXTENDED LOG (2024-03-08 by XXL-Webdesign) #####################################
## https://forum.shopware.com/t/warenkorb-leert-sich-ohne-grund/102915
## https://stackoverflow.com/questions/73064576/set-loglevel-to-debug-without-setting-app-env-to-debug
## https://stackoverflow.com/questions/59501658/how-to-exclude-deprecation-messages-from-logs-in-symfony-4
monolog:
channels:
- 'deprecation'
handlers:
main:
# type: stream
# path: "%kernel.logs_dir%/%kernel.environment%.log"
type: rotating_file
path: "%kernel.logs_dir%/conf_pkgs_prod_monolog_yaml_MOD_%kernel.environment%.log"
level: debug
channels: ["!event","!doctrine","!deprecation"]
# uncomment to get logging in your browser
# you may have to allow bigger header sizes in your Web server configuration
#firephp:
# type: firephp
# level: info
#chromephp:
# type: chromephp
# level: info
console:
type: console
process_psr_3_messages: false
channels: ["!event", "!doctrine", "!console"]
####################################################################################################################
Achtung!
Die Datei kann im original DEV-Script (/your-sw6-path/vendor/shopware/core/Framework/Resources/config/packages/dev/monolog.yaml) innerhalb weniger Tage mehrere GB groß werden!
90% der Meldungen waren jedoch php deprecated Meldungen. Die habe ich jetzt aber in dem u unten stehenden Script gefiltert / deaktiviert, so dass die Log-Datei zwar immernoch recht schnell größer wird, aber nicht so schnell wie zuvor.
Außerdem habe ich den type: stream durch rotating_file ersetzt, was dazu fürhrt, dass die Dateien auf Tage gesplittet werden, statt in einer großen Datei.
Zum einsehen der Log-Files entweder in das /var/log/ Verzeichnis gehen und die Log-Datei herunterladen oder das Frosh-Tools Plugin installieren und dann bequem über den grünen / roten Punkt neben „Administration“ oben links oder über Einstellungen - Erweiterungen - Plugins - Tools.
Dann auf Log-Viewer, Logfile auswählen und dort stehen alle Einträge.
@PromoID Stimmt, danke dass du mich daran erinnerst. Einer meiner Jungs hat am Anfang alle Warenkörbe über die Datenbank geleert. Vielleicht wird das auch schon reichen.
@easyTEC Was genau meinst du damit? Der Eintrag „session-xxxxxxxxxxxxxxxxx“ gehört nicht in das Verzeichnis. Es kann sich keiner von uns erklären, warum es dort auftaucht und was genau sich die Shopware AG dabei gedacht hat. Der von mir veröffentlichte Script sucht lediglich nach diesem Muster und führt die von Shopware zur Verfügung gestellte Funktion zum Leeren des Caches aus. Was genau kannst du nicht replizieren?
@I_c_h Sorry, ich bin nicht so tief in der Materie und versuche nur unseren Shop anzupassen. Die session- werden bei uns weiterhin erstellt, nur seltener. Heute hat Dein Script trotz aller Updates den Cache wieder gelöscht. Könnte man das Script auch so umschreiben, daß nur die Session-Einträge gelöscht werden und nicht der gesamte Cache? Ich bekomme das leider nicht hin. Oder funktioniert das nicht?
Eine zweite Frage: Wir lassen Dein Script als Hintergrundprozeß laufen. Kann man im Script den Cache wieder aufwärmen, wenn das Löschen erfolgreich abgeschlossen wurde oder muß man einen zweiten Prozeß aufsetzen, der auf den ersten wartet?
Moment! Führst du dies als Cronjob aus? Wenn du das Skript im Screen ausführst, also screen bash sessiontest.sh, kannst du die Instanz mit „Strg + A“ und dann „D“ verlassen, und mit screen -r wieder aufrufen. Die While-Schleife veranlast jede Sekunde das grep nach dem Muster zu suchen. Wenn es fündig wird, und dafür sorgt die IF-Abfrage, dann (then), wird die Shopware-Funktion cache:clear ausgeführt.
Das bedeutet nicht, dass das Skript das Muster löscht, sondern Shopware entfernt die Daten und erstellt dann neue. Daher denke ich nicht, dass es eine gute Idee ist, die Datei einfach zu entfernen.
Melde dich in der Datenbank an und leere zuerst alle Warenkörbe. Vielleicht löst dies tatsächlich das Problem.
DELETE FROM cart WHERE customer_id IS NULL;
Oder noch besser. Wie es @PromoID gemacht hat und mit weniger Risiko verbunden ist: Gehe einfach zu Einstellungen > Shop > Warenkorb und stelle „Zeit in Minuten, die ein Kunde Zeit hat, eine Transaktion abzuschließen“ auf eine Minute ein und entferne dann den Eintrag nach einer Minute wieder.
Sag mal bitte dann ob das Problem noch immer auftaucht.
@I_c_h Weder noch, ich habe den Bash durch ein angehängtes & in den Hintergrund geschoben. Dadurch läuft er jetzt durchgehend als Prozeß, bis ich ihn über kill wieder beende. Klappt wunderbar. Dadurch hatte ich mir den Cron oder CLI gespart, aber das wäre mein nächster Schritt gewesen.
Ich wollte jetzt nur noch gerne das Aufwärmen des Cache mit in das Script übernehmen. Wenn das nicht geht, müßte ich wohl ein Cron anlegen.
Das mit dem Warenkorb werde ich nächste Woche mal ausprobieren und mir die cart in der Datenbank ansehen. Aber eigentlich läuft alles stabil, bis auf das manchmal dieses Muster das Script auslöst.
Eine Idee ist noch, daß das System Probleme macht, wenn man mehrere Verkaufskanäle im Einsatz hat. Das Warenkorb-Problem trat bei mir nur im Produktivsystem mit mehreren Verkaufskanälen auf, nicht in der Testumgebung. Ich hatte schon mal Probleme im Produkt-Export, daß der Verkaufskanal zufällig zugeordnet wurde. Aber das ist nur Spekulation.
Wir hatten vorher 8.3 als version, da war alles in ordnung. Jetzt wo 8.7 installiert ist, haben wir den Fehler auch. Hab es mal als Thema unter Update 6.5.8.3 auf 6.5.8.7 nur Probleme geschrieben, aber bevor ich das hier gefunden haben. Vorher lief der Shop ohne Fehler. Ja gut wir hatten eine URL die nicht zu uns gehört auf unsere IP als Mapping Fehler, aber das war nicht das Problem. Ansonsten läuft der Shop seit Jahren Fehlerfrei, mit Worker und Co. Plugins haben wir nicht viele.
).
