Neu Warenkorb plötzlich leer, bei "Warenkorb anzeigen"

[der_Martin]

Hallo,
ich habe (seit heute Morgen) das Problem, dass ich Artikel in den Warenkorb lege. Da Sind sie auch.
Wenn ich auf "Warenkorb anzeigen gehe", ist aber der Warenkorb plötzlich leer???

Hab schon mehrere Beschwerden von Kunden erhalten.

Ist der böseseste denkbare Fehler! Jemand ne Ahnung woran das liegen kann?

https://www.fischer-lahr.de/

 

[ag-websolutions.de]

klingt nach Session fehler (mal "mit www" ... mal "ohne www") ... Link zum Shop??

 

[der_Martin]

https://www.fischer-lahr.de/

ich leite eigentlich nach www weiter

 

[der_Martin]

ich habe nun in ein datenbank-tool reinegschaut um ein backup der DB zu machen... und das datenbnaktool gibt mir diesen fehler aus. Scheint damit zusammen zu hängen. Was tun?

????????

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0


Habe 4 Shops auf dem Server laufen. der obige ist der einzige der das problem hat....

 

[der_Martin]

Hab die Datenbank standardmäßig bereinigt und Tabellen repariert.... dann gings's wieder wieder.

Kurz darauf wieder nicht.

Dann nächster üblicher verdächtiger: Template- Cache leeren.
Dann gings auch wieder.


Hilft mir aber nicht weiter. Bekomme gleich den Kasper.
Kenne die Ursache nicht.... darf nicht sein....

????

 

[der_Martin]

Nachtrag: habe in allen Shops auf dem Server nun das Problem....

 

[martinwolf]

Ist ja jetzt kein Shop-spezifisches Problem, sondern generell ein Problem, dass die Sessiondatei nicht geschrieben werden konnte, weil der Pfad zu dieser falsch gesetzt ist.

Bei welchem Hoster läuft der Shop? Gab es hier ggf. Änderungen an der Serverkonfig? Einfach mal den Hoster über diesen Fehler in Kenntniss setzen.

 

[der_Martin]

ja, sehe ich nun auch so. Zuerst war es ein Shop... nun alle.
Ist demnach wohl ein Server-Problem. Ich versuche mich gerade bei 1&1 durch zu telefonieren und einen Server-Menschen dran zu bekommen (seit 15 min in der 1&1 Musik-Schlange drin...)....

 

[der_Martin]

zur Info: Ist wohl ein Server-Problem. Habe das Problem, dass die Sessions nicht geschrieben werden können, unabhängig von den JTL-Shops z.B. https://yerd.fischer-lahr.de/ , auch in tools wie mySQLdumper...
Mal geh'ts, mal nicht. Als ich bei 1&1 anrief ging es blöderweise. Der session tmp-ordner ist beschreibbar und nicht voll...
dann ging's wieder nicht.

Man sagte mir bei 1&1 aber, dass es möglicherweise ein bekannter Bug im Dateisystem von 1&1 ist. Man wollte es noch mal überprüfen.
1&1 empfahl mittefristig den tmp ordner, in den PHP die Sessions schreibt, per ini ins eigene Verzeichnis und nicht in den Server-Root zu legen.....

 

[ag-websolutions.de]

Dann pass aber auf, dass du dir deinen Webspace nicht zumüllst, sonst ist der irgendwann voll und/oder du bezahlst bei 1&1 drauf wenn du über das Speicherlimit kommst.

Der GC weiß ja im Zweifel nichts davon und räumt das Verzeichnis nicht automatisch auf.

Immer wieder was neues mit 1&1 ... nur meistens nix gutes

 

[der_Martin]

ich warte mal ab was 1&1 dazu sagt.

falls noch jemand ne Idee hat.... ?

Grundsätzlich funktioniert es nun... aber irgendwann verliert der Shop wieder die Session.
Dies passiert dann bei allen 3 Shops, die auf dem Server laufen, etwa gleichzeitig!!
Dann lässt sich kurzzeitig auch nichts in den Warenkorb speichern.. es scheint keine Session aufgebaut zu werden.

Habe bei den Shops öfters auch mal einen CSRF (Cross site request forgery) beim Einloggen in den Admin. Hat mich bisher nicht weiter gestört, da ich immer irgendwie rein kam. Aber ich schätze, dass es mit dem Session-Problem zusammenhängt....

 

[css-umsetzung]

1&1 hat bei älteren Servern das Problem das sie aufgrund fehlerhafter Software die Sesseions nicht löschen können wenn es zuviele werden.

Du kannst die sessions in einen eigenen Ordner verlagern dann hast du eventuell Ruge, solltest dich aber darum kümmern dir was eigenes zuvschreiben das die sessions dannn mehrfachvam Tag prüft und killt.

Ich würde 1&1 mal mragen ob du schon auf einer 64bit Kiste bist und das sofort in Auftrag geben wenn dem nicht so ist, bzw. den Anbieter eh schnellstmöglich verlassen (meine Meinung).

Es könnte auch sein das durch den cache zuviel Files auf dem Server liegen, denn auch da hat 1&1eine begrenzung.

 

[der_Martin]

Danke.

1&1 meinte die Begrenzung sei nicht erreicht. Die Maschine ist relativ neu. Wir sind vor ca. 1,5 jahren von unserer uralt 1&1 Maschine auf die neue umgezogen.

meine vermutung ist, dass irgendwas eventuell zu große temp Dateien schreibt und der Server damit beschäftigt ist den Ordner zu löschen. Aber hierrfür stecke ich zu wenig in der Materie drin um das zu beurteilen.
eine andere vermutung wäre, dass sich die Sessions der 3 Shops in die Quere kommen (????).
eine dritte Vermutung: die Sessions werden durch den Wawi abgleich gekillt (???). Habe früher bei Gambio schon beobachtet, dass ich z.B. aus dem Admin fliege, nachdem die Wawi ihren Abgleich gemacht hat. Typisch scheint mir auch, dass etwa im Rhythmus des Wawi Abgleichs alle 3 Shops ihre Sessions verlieren.
Eine weitere Vermutung wäre, dass sich Domains bei der Sessions in die Quere kommen. Das Problem trat erst auf, nachdem wir unseren dritten Shop gelauncht haben, der unter der selben second level Domain läuft wie der zweite. https://www.fischer-lahr.de und https://yerd.fischer-lahr.de ... das ist zugegeben eine sehr seltene Konfiguration. Der jüngere Shop sollte aber durch die starke und alte Domain fischer-lahr.de erst mal an Trust gewinnen.

Aber das sind nur Hypothesen!!!

 

[css-umsetzung]

Du kannst die Menge der Sessions die geschrieben werden verringern, indem du in der config vom Shop

das hier einträgst:
define('SAVE_BOT_SESSION', 3);

hier Teile aus dem Zitat wo das mal angesprochen wurde:

Die Anzahl und Größe lässt sich übrigens deutlich minimieren
Sollte allerdings nur gemacht werden, wenn man ein auf dem EVO-basierendes Template und den Objektcache nutzt.
Das sorgt dann dafür, dass weniger Daten wie noch zu Shop3-Zeiten in der Session gecacht werden und das nicht jeder Aufruf durch eine Suchmaschine eine neue Session erstellt.

1&1 meinte die Begrenzung sei nicht erreicht. Die Maschine ist relativ neu. Wir sind vor ca. 1,5 jahren von unserer uralt 1&1 Maschine auf die neue umgezogen.

Das sagten Sie meinem Kunden auch immer weil sie immer dann schauten wenn es wieder OK war.
1,5 Jahre ist lange her, du kannst also noch immer auf einer alten Kiste sitzen die diesen Fehler hat.

Das beste ist es, wirklich, je Shop ein eigenes Sessionverzeichnis anzulegen, das haben wir damals auch machen müssen obwohl der Shop gar nicht so viel Traffic hatte, danach kam dann die Begrenzung der Anzahl der Files, wo wir dann die Notbremse gezogen haben.

Da du sagst, dass du das Gefühl hast das dies durch den Abgleich passiert, solltest du den mal manuell ausführen, nachdem du die sessions in dein eigenes Verzeichnis gelegt hast, dort kannst du das per ftp ja gut überwachen, was gelöscht wird.

 

[der_Martin]

Danke dir, "css-umsetzung"!

define('SAVE_BOT_SESSION', 3); hab ich nun bei allen Shops gesetzt. Ich brauch die sessions der Bots nicht ...

PS: Bevor wir die 3 produktiven Shops aufgesetzt haben, hatte ich einen produktiven JTL Dummy- Shop als Live-Test aufgesetzt. Bei diesem wurde mir einmal "von einem Bot " 400.000 Objektcache Dateien auf den Server geschrieben. Bei 1 Mio möglicher Dateien hat mir das den Server - sprich alle Gambio Shops - gekillt, da sie kein Speichervolumen mehr hatten.... habe einen halben Vormittag lang verzweifelt in den Gambio-Shops nach dem Fehler gesucht, bis ich festgestellt habe, dass mir der Test-Shop (mit so gut wie keinen Besuchern) den Server vollgeschrieben hat. Seither habe ich den Objektcache aus... die JTL Shops laufen auch so recht schnell!

Ich werde noch mal mit 1&1 reden. Dann werde ich den session.save_path in PHP manuell auf die einzelnen Verzeichnisse legen und kann dann weiter schauen. Bei leeren Warenkörben mache ich mich sonst bei meinen Kollegen unbeliebt...

 

[ag-websolutions.de]

Seither habe ich den Objektcache aus...

Dann solltest du den OC via Redis aktivieren, dann werden keine Dateien geschrieben.
Voraussetzung ist, dass dein Server/Hoster Redis untestützt.

 

[css-umsetzung]

Das Problem ist, wenn du wie ich vermute "nicht" Redis verwendest, weil 1&1 das nicht aktiviert, musst du den Weg über den "erweiterten Dateien" Cache gehen, und der macht richtig Alarm, der kann dir bei drei Shops auch ganz schnell das File Limit sprengen.

1&1 Server sind wirklich nicht leicht zu Handeln wenn Sie managed sind, ich habe einen anderen Kunden, der musste unter anderem deswegen seinen Cache deaktivieren, was natürlich extrem problematisch ist, in unserer "ich muss der schnellste sein" Welt.

 

[der_Martin]

kein Redis bei 1&1. Und auch sonst nix.
Hab da nur die Möglichkeit den PHP7 Cache zu nutzen, der die Dateien vorkompiliert.
Troztdem sind die JTL4 Shops schneller als die Gambios (mit Cache) jemals waren.

Mag nicht auf 1&1 schimpfen. Die sind besser als ihr Ruf.
Werde einen Serverumzug jedoch ins Auge fassen. Aber mag das nicht in der Saison machen. Die Serverprobleme treffen mich ausgerechnet jetzt, wo mein eigener Shop Saison hat und ich ständig Kunden am Tel. haben die über Schlauchtrommeln und Blumentöpfe reden wollen LOL

 

[der_Martin]

zur Info (ich hoffe ich kann das Thema nun abschließen
und mich wieder meinen Blumenkübeln und Gartenkaminen widmen ):

Ich habe jetzt bei 2 der 3 Shops den session.save_path per php.ini (bzw optional .user.ini bei 1&1) in einen Ordner im jeweiligen Verzeichnis gelegt. Damit kommen sich die Shops bei abkackenden sessions hoffentlich auch nicht mehr in die Quere.

Bei dem frisch aufgesetzten Shop mit dem die Probleme letzte Woche auf dem Server begannen, wurden in der ersten Minute (rund 60 sek) 22 Session-Dateien mit insgesamt 51 MB in den Session Ordner geschrieben (Screenshot Anhang).
Nach 30 Minuten sind es nun schon 134 Dateien mit 416MB. Das hat wohl den auf 1 GB begrenzten /tmp Ordner, der alle Sessions des Servers handelt, permanent an die Grenze gebracht.

Solange es nur Speichervolumen ist, interessiert es mich nicht. Das hab ich endlos auf der Maschine. Aber ich muss die Dateizahl im Auge behalten.
Ich suche nun noch nach einem Weg dass ich diese Ordner ein mal in der Nacht mal automatisch leeren kann....

Ich hoffe, dass Problem ist damit nun gelöst.

Danke für die Hilfe!!!!
LG

Martin

 

[css-umsetzung]

bei einem 1&1 Server der Managed ist, darfst du auch auf den Server,
Hier wäre es angebracht jede Stunde ein script laufen zu lassen, dass alle Files > 30min. löscht, denn eine Session sollte ja nach 15 Minuten eh ablaufen.

Und du hast eben das Problem, das es ab einer bestimmten Files Menge nicht mehr möglich ist diese zu löschen.

Das kannst du wie gesagt über ein Shell Script lösen, ich poste hier keine Links, denn ich möchte nicht dafür verantwortlich sein das du auf einmal deinen Server killst

"linux files älter als x minuten löschen" wäre eine mögliche Suche