In unregelmässigen Abständen crasht unser EE System, d.h. statt Shops gibt es für den Käufer nur noch weisse Browserseiten (blank pages). Auch den Admin gibt es nur noch in Reinweiss.
Hast du das schon mal erlebt? Wenn ja, was hast du dagegen unternommen?
Details:
diese Störungen passieren ohne unser Zutun (also nix mit templates rummachen oder so)
wenn ich alle files in /tmp lösche, funktioniert alles wieder wunderbar (bis zum nächsten Crash)
das EXCEPTION_LOG zeigt eine grosse Menge von CLASSNOTFOUND Exceptions. Die nicht gefundenen Klassen in den Logs sind je ganz andere. Kein System erkennbar
passiert der Crash, sind ALLE unsere Shops in der EE betroffen.
Ich vermute, dass irgendwelche vorkompilierten und gecashten Klassen nicht gefunden werden, die in den tmp-Dateien eigentlich drin sein müssten.
Wenn du Hinweise hast, wäre ich sehr dankbar, sie hier zu hinterlassen.
Und ja - wir setzen Module ein, aber was meint: " … die ständig Daten abgreifen"?
Daten werden natürlich ständig abgegriffen, immer dann, wenn ein Bing- oder Google-Bot vorbeikommt, oder ein potentieller Käufer, und wir haben auch die SOAP-Schittstelle in Betrieb, über die ebenfalls Daten abgerufen werden. Der letzte Crash fand jedoch zu einer Uhrzeit statt, an der kein SOAP Request aktiv war. Nur normale http-Anfregen, 1,2 user mit forcesid im GET-parameter.
Ja, ich meinte auch mal was von einem Bugtracker-Eintrag gelesen zu haben, aber welcher? Ich suchte heute schon die Liste rauf und runter. Fällt es dir noch ein?
Herzlichen Gruss + Hoffnung auf weitere Ideen von euch!
der eintrag steht sicherlich schon halbes jahr da drin, ggf. sogar noch länger, damals für die 4.3.2 - wurde von andreas ziethen eingetragen, such mal ggf. mit dem stichwort treepodia
Also bei mir hat sich grade auch der shop verabschiedet. Tmp leeren hat nicht geholfen.
Wenn ihr selber mal schauen wollt einfach auf www.apollocf.de gehen. Heute Mittag ging er noch einwandfrei. Was ist das. Wobei bei mir ist das die CE Version.
Das Problem ist das ich nicht mal mehr in den Admin Bereich rein komme. Der setzt mich immer wieder auf die Hauptseite zurück. Ich werde das mal versuchen. Hoffentlich klappts.
@martina:
Der Bugtracker-Eintrag von Andreas Ziehten mit Stichwort “treepodia”, den ich fand, bezieht sich NICHT auf einen crash, sondern auf slow perfomance, und zudem auf V 2.7.
Wir setzen übrigens keine eFire-Connectoren ein.
Ich danke dir dennoch für’s Mitdenken!
Weiss sonst noch jemand von euch was über die Caching-Logik? Da wir Oxids Caching gar nicht aktiviert haben, gehe ich davon aus, dass es sich in /tmp um kompilierte Smarty-Templates handelt. Ist das richtig?
Mein Problem ist, dass ich den Fehler nicht reproduzieren kann. Ich habe nur das Exception Log und einen Chef, der zurecht sauer ist.
ich setze auch keine EE2.7 mehr ein, andreas hat mir aber per mail bestätigt, daß die dort genannten probleme auch für meine ee4 (zum fragezeitpunkt 4.3.2, jetzt 4.4.5) gilt.
dann war hier noch nen beitrag mit so nem ecela… keine ahnung wies nochmal richtig geschrieben wird, bin ja kein techni
[QUOTE=laramarco;58876]
dann war hier noch nen beitrag mit so nem ecela… keine ahnung wies nochmal richtig geschrieben wird, bin ja kein techni[/QUOTE]
Es geht um den eaccelerator, siehe folgenden Beitrag, vielleicht hilft es ja:
Unsere Oxid EE ist bei domainFactory gehostet, und die Fehlernatur des Crashs ist eine andere: Keine PHP Errors, sondern Oxid Errors, und Apache liefert ganz wunderbar eine leere Seite ohne frühreife Headers oder so. Wenn Oxid eine Class Not Found-Exception loggt, ist der Grund auch keine überlange Script-.Laufzeit. Im Gegenteil: ist der Crash-Zustand einmal erreicht, wird jeder BrowserRequest in Millisekunden mit einer leeren Seite beantwortet.
Das Oxid Exception Log sagt ja auch, was passiert: oxNew() versucht eine PHP-Klasse zu laden und findet sie nicht. Da nach Leeren von /tmp die Klasse wieder gefunden wird, liegt es offensichtlich nicht daran, dass die Klasse nicht existiert, sondern dass die kompilierten tmp-Files korrupt sind. Zudem nennt das Exception Log auch ständig andere Klassen, die nicht gefunden werden können. Also ist das ganze /tmp-System korrupt geworden. Nur: durch was? und vor allem: wie behebe ich das?
hab ich dich soweit richtig verstanden, in dem moment wo du temp leerst kommste wenigstens in admin rein ??
wenn ja, schalte doch mal die module aus, auskommentieren mit # davor (ich würd erstmal alle die zu efire gehören auskommentieren)
@firefax, vadderdag is bundesweiter feiertag, da nützt dich null nix support und auch kein first level WV, da wirste vor freitag null nix hilfe bekommen, wobei … abwarten was wirklich grund war und ist …
@firefax
Ja, ich habe den Support angeschrieben. Ich warte noch auf eine Antwort.
@Martina
"hab ich dich soweit richtig verstanden, in dem moment wo du temp leerst kommste wenigstens in admin rein " - Nein, nicht richtig verstanden.
Wenn ich tmp leere, funktioniert ALLES wie gewünscht ganz wunderbar mal wieder für 3-4 Wochen, nicht nur der Admin.
oh Mann - dieser Thread liest sich wieder wie einmal im grossen Heuhaufen herumgestochert… Ich würde vorschlagen, dass man versucht, das Problem einzugrenzen (das nichts mit der Edition zu tun haben dürfte), bevor wir wieder zum allgemeinen Gemoser überschreiten…
Dazu werden einige Informationen zusätzlich benötigt:
[ul]
[li]Da wir von einer 4.3.2 reden, läuft der Shop vermutlich schon ein paar Tage. Seit wann tritt das Problem auf?[/li][li]Wenn niemand von Euch etwas geändert hat: Hat der Hosting-Provider u.U. eine Änderung vorgenommen und Euch evtl. nicht unterrichtet? Bitte prüft die Systemvoraussetzungen nochmal ab.[/li][li]Du (@finnegan) arbeitest nicht zufällig auf der Live-Umgebung? Falls ja: Spiegel Dir den Shop! –> Tritt das Phänomen noch auf?[/li][li]Schmeiss dort bitte alle Module raus –> Tritt das Phänomen noch auf?[/li][li]Prüfe die Installation mit einer oxchkversion. Wie ist das Ergebnis?[/li][li]Setze in der Testumgebung einen Parallelshop auf um herauszubekommen, ob das Phänomen eher in der Datenbank oder in den Dateien zu suchen ist. [/li][/ul]
Prinzipiell sieht es aufgrund der Fehlermeldung für mich so aus, als ob entweder originale Dateien verändert wurden (herauszubekommen mit einer oxchkversion) oder auf dem Server irgendetwas nicht stimmt (durch Spiegelung ausgrenzbar). Ggf. könnte es sogar mit einem Hardwarefehler (oder zu wenig Plattenplatz) auf dem Server zu tun haben, je nachdem, wie Eure Produktivumgebung aussieht.
Und nein, der Support wird morgen nicht erreichbar sein, weil wir einen Feiertag (Christi Himmelfahrt) haben, der in unseren Kulturkreisen nicht unüblich ist. Allerdings gibt es die Option eines Super-Sonder-Support-und-Wartungsvertrages, bei dem es erweiterte Erreichbarkeit für solche Clashes am Wochenende und an Feiertagen gibt.
Falls ich je eine Antwort bekomme, poste ich sie hier.
Bereite Dich bitte darauf vor, dass dieser Post umgehend wieder gelöscht wird. Abgesehen davon, dass Du eine Authorisierung dafür brauchst, ist es allein durch die Forenregeln ausgeschlossen.
Könnte das dieser “reaktivierte” bug sein der wie andreas ziehten sagt sogar scheinbar noch da ist da der mechanismus nicht verändert wurde? Das wäre fatal. Bei dir ist der fehler übrigens auf jeden fall noch drin, da du ja die 4.3.2 hast und der bug laut entwickler in der 4.4.1 gelöst wurde.
Weiss sonst noch jemand von euch was über die Caching-Logik? Da wir Oxids Caching gar nicht aktiviert haben, gehe ich davon aus, dass es sich in /tmp um kompilierte Smarty-Templates handelt. Ist das richtig?
Nein. Dort wird auch der class file cache, langcache und noch ein paar andere kleine caches gespeichert die du so als user nicht ohne weiteres deaktivieren kannst. Das falsche schreiben des class path caches scheint dein problem zu verursachen.