SUPEE-6788 (Mögliche) Cache-Probleme

8

Seit wir den SUPEE-6788-Patch auf der Site eines Clients angewendet haben, ist die Site ungefähr einmal am Tag ausgefallen und das einzige, was sie zurückzubringen scheint, ist das Löschen des Caches. Wir haben uns die Protokolle angesehen und einige davon scheinen zu enthalten: "Der Front-Controller hat 100 Router-Match-Iterationen erreicht." Dieses Problem trat nicht auf, bevor der Patch angewendet wurde. Hat jemand eine Idee, was dies verursachen könnte? Einige Leute sagen, es könnte ein Cache-Fehler in der Magento-Ausgabe sein, aber ich kann es nicht sagen. Jede Eingabe wäre hilfreich!

Einige zusätzliche Hinweise:

  • Es gab keine schweren Lasten auf dem Server, als er ausfiel, also ist das kein Faktor.
  • Ja, alle vorherigen Patches wurden erfolgreich angewendet.
  • Wir verwenden Memcache, um den Cache zu speichern.
Daryl Gochnauer
quelle
Nicht sicher , ob dies verwandtes , aber dieses Modul ist speziell für den Einsatz mit den neuen Blöcken und Variablen hinzugefügt SUPEE-6788 github.com/EcomDev/SUPEE6788-PerformanceFix
David Manners
Als weiteren Datenpunkt haben wir eine Site, bei der dieses Problem die Site bisher zweimal mit dem Fehler "100 Router-Match-Iterationen" heruntergefahren hat. Es begann erst mit SUPEE-6788. Nach dem ersten Mal habe ich den AmpersandHQ-Patch (SUPEE-4755) angewendet, aber das Problem trat einige Tage später immer noch auf, sodass der Patch das Problem für uns nicht behebt. Wir führen Magento 1.7.0.2 mit dem Redis-Cache aus.
Nick

Antworten:

3

Ich selbst und ein anderer Entwickler hatten ein ähnliches Problem, aber wir scheinen es gelöst zu haben, indem wir den in diesem GitHub vorhandenen Patch angewendet haben: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

Die Ursache scheint eine Art Race-Bedingung zu sein, bei der der Cache von einem Prozess geleert wird, während er von einem anderen erneut instanziiert wird. Ich konnte ihn reproduzieren, indem ich die ebenfalls auf diesem GitHub aufgeführten Schritte befolgte.

Ich habe mit Magento ein Support-Ticket für dieses Problem geöffnet und habe den Verdacht, was es seit dem Patch verursacht hat, warte aber auf eine Rückmeldung.

Weitere Informationen finden Sie in der folgenden Frage: Probleme mit nicht gestalteten Seiten, fehlerhafte Pfade, Verlust der Layoutkonfiguration nach Anwendung des SUPEE-6788-Patches .

Persata
quelle
Wurde dieses Update auf 1.8.1.0 mit installiertem SUPEE-6788 getestet?
Daryl Gochnauer
@ dgwexdev13 Ich habe es nicht auf 1.8 getestet, aber ich habe den Patch auf 1.9 und 1.13 gleichzeitig entwickelt. Ich glaube nicht, dass sich das betreffende Modul (Mage_Core_Model_Config) in einem LONG geändert hat, so dass der Patch so ziemlich für alle Versionen gelten sollte. Ich habe gesehen, dass dieser Patch mit 1,12, 1,13, 1,14 Systemen mit installiertem SUPEE 6788 zufriedenstellend läuft.
Luke Rodgers
Ps - Bitte aktualisieren Sie hier, wenn Sie etwas von Magento gehört haben. Danke
Daryl Gochnauer
Ich befürchte, dass die Anwendung von SUPEE-4755 zusammen mit SUPEE-6788 nicht viel dazu beiträgt, die Fehler "100 Iterationen erreicht" zu stoppen. Ich habe beide auf eine Reihe von nicht verwandten Websites angewendet und sehe immer wieder gelegentliche Abstürze auf allen. Hat jemand mehr Glück gehabt?
Jan Tomka
1

Wir haben das gleiche Problem mit 3 Sites Version 1.8.1. Es begann nach SUPEE 6788 zu erscheinen. Das Update von oben löste das Problem nicht. Eigentlich scheint es eine Veränderung zu geben. Vor dem Fix stürzten die Sites zweimal am Tag ab, jetzt war der letzte Absturz nach 2 Tagen. Aber möglicherweise hängt es mit der Last zusammen. Die 3 Seiten sind klein und nicht sehr geladen. Dieses Problem tritt bei einer großen Site mit Version 1.6.2 und SUPEE 6788 nicht auf. Alle Sites befinden sich auf demselben Server - die 3 mit Version 1.8.1 und die große mit Version 1.6.2

Dimitar Dimitrov
quelle
Dies liefert keine Antwort, eher für einen Kommentar geeignet. Sie sollten einige gute Fragen stellen und auf der Website einige gute Antworten geben. Wenn Sie sich einen guten Ruf erworben haben, können Sie auch Kommentare veröffentlichen.
Prateek
1
Ja, ich verstehe, aber wenn ich versuche zu kommentieren, habe ich die Meldung "Sie müssen 50 Ruf haben, um zu kommentieren". Und ich denke, es ist eine wichtige Information, dass dies auch anderen Websites passiert. Und scheint versionenspezifisch zu sein.
Dimitar Dimitrov
@ DimitarDimitrov im Grunde das gleiche - wir hatten einen anstrengenden Tag am Dienstag und die Seite ging ungefähr einmal pro Stunde aus. Durch Verschieben des Konfigurationscaches von Redis und einfaches Verwenden des Dateibasis-Caching (ich verwende immer noch Redis für FPC) konnte ich den Speicher stabilisieren.
Phil Birnie
Nach dem großen Laden mit Version 1.6.2. stürzte viele Male mit einem anderen Fehler ab: "Unzulässiges Schema angegeben, nur alphanumerische Zeichen sind zulässig" Wir mussten den Patch zurücksetzen. 24 Stunden seitdem keine Abstürze mehr und alle unsere Geschäfte sind stabil. Ich mag die Idee, ohne den Patch zu arbeiten, wirklich nicht. Wir versuchen, den Grund mit einer Testinstallation zu finden, aber das Problem ist, dass sie nicht abstürzt. Wahrscheinlich sind echte Aktionen erforderlich, um es zum Absturz zu bringen, und ich weiß nicht genau, welche. Wir haben versucht, den Absturz mit ab zu provozieren, aber es scheint nicht lastabhängig zu sein.
Dimitar Dimitrov
Ich habe vergessen zu erwähnen, dass wir einfaches dateibasiertes Caching verwenden. Der Server ist mit PHP 5.4 und Opcache, aber das Deaktivieren von PHP-Caching hilft nicht
Dimitar Dimitrov
1

Wir haben den Site-Cache von Memcache auf Redis umstellen lassen und dann alle 12 Stunden einen Cronjob hinzugefügt, um den Cache zu sichern. Es ging von einem Absturz einmal am Tag bis ungefähr 4-5 Tage, bevor es wieder abfiel. Wir haben dann den Cronjob so angepasst, dass er alle 6 Stunden abgeladen wird und seitdem ist er nicht mehr gesunken (seitdem sind ungefähr 3-4 Tage vergangen). Weder wir noch das Hosting-Unternehmen können das eigentliche Problem aufspüren, aber dies scheint eine funktionierende Lösung für uns zu sein. Hoffe das hilft jemandem.

Daryl Gochnauer
quelle
Ich empfehle, dass Sie das Protokollierungsformular hier eingeben : github.com/AmpersandHQ/… Auf diese Weise sehen Sie, welcher Code kontinuierlich das Speichern von Konfigurationscache-Beschädigungen auslöst.
Luke Rodgers
1

Ich habe heute Morgen den AmpersandHQ-Debugcode hinzugefügt und hatte gerade die Ausnahme "Front-Controller hat 100 Router-Match-Iterationen erreicht", die in einem Zeitraum von 2 Minuten etwa 75 Mal aufgetreten ist. Aber dieses Mal, vermutlich weil der Debug-Code den beschädigten Cache-Eintrag nicht speichert, ist die Site immer noch aktiv, ohne dass alle Ausnahmen erhalten (ich habe den Cache nicht geleert).

Ich habe mich noch nicht damit befasst, um zu untersuchen, aber korrupt-cache.log enthält:

2015-11-22T03:42:42+00:00 DEBUG (7):
#0 app/code/core/Mage/Core/Model/App.php(1147): Mage_Core_Model_Cache->save('<admin><design>...', 'config_global_s...', Array, NULL)
#1 app/code/core/Mage/Core/Model/Config.php(552): Mage_Core_Model_App->saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#2 app/code/core/Mage/Core/Model/Config.php(474): Mage_Core_Model_Config->_saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#3 app/code/core/Mage/Core/Model/App.php(421): Mage_Core_Model_Config->saveCache()
#4 app/code/core/Mage/Core/Model/App.php(343): Mage_Core_Model_App->_initModules()
#5 app/Mage.php(683): Mage_Core_Model_App->run(Array)
#6 index.php(87): Mage::run('', 'store')
#7 {main}

Dies ist auf Magento 1.7.0.2 mit Redis-Cache und AmpersandHQs SUPEE-4755-Patch bereits angewendet.


Update vom 2. Dezember 2015: Hier ist ein weiterer Fehler mit der vollständigen Stapelverfolgung:

2015-12-02T20:02:27+00:00 DEBUG (7):
#0 app/code/local/Mage/Core/Model/App.php(1156): save('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#1 app/code/local/Mage/Core/Model/Config.php(552): saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#2 app/code/local/Mage/Core/Model/Config.php(474): _saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#3 app/code/local/Mage/Core/Model/App.php(430): saveCache()
#4 app/code/local/Mage/Core/Model/App.php(343): _initModules()
#5 app/Mage.php(683): run(Array)
#6 index.php(87): run('', 'store')
Nick
quelle
Fantastischer Kumpel. Vielen Dank für die Veröffentlichung Ihrer Stapelverfolgung. Könnten Sie bitte diesen Kern lesen? gist.github.com/convenient/2a30572d6d4bcae9796c Ich habe eine Idee, um es darauf zu beschränken, ob es sich um einen useCache = trueObjekt-Cache-Fehler oder etwas ganz anderes handelt.
Luke Rodgers
OK, ich habe diese zusätzlichen Dateien gepatcht. Vielen Dank für die Arbeit an den Patches. Letzte Nacht, nachdem ich gepostet habe, ist der Fehler innerhalb von 30 Minuten noch zweimal aufgetreten. Aber danach ist es seit 15 Stunden nicht mehr passiert. Ich bin mir also nicht sicher, wie ich vorhersagen soll, wann es wieder passieren könnte.
Nick
Okay cool, bitte halte mich auf dem Laufenden. Vielen Dank
Luke Rodgers
Ich habe 2 weitere 100 Router-Match-Fehler erhalten, nachdem ich den zusätzlichen Patch angewendet habe, den Sie mir im Kern gegeben haben. Das hat das Problem also nicht behoben. Nach dem ersten habe ich den Debug-Code leicht geändert, um den gesamten Stack-Trace anstelle des abgeschnittenen PHP-Codes zu erhalten. In meinem Kommentar hier war kein Platz, daher habe ich meinen ursprünglichen Beitrag oben so geändert, dass er die neue Ablaufverfolgung enthält.
Nick
Es ist also ein Fehler im Thema des Moduls "Suchen". Unsere Website verwendet das Suchmodul nicht und es sieht so aus, als ob diese Firma jetzt sowieso nicht mehr existiert (aber das Modul wurde früher standardmäßig mit Magento ausgeliefert), daher habe ich das Modul für die Zukunft deaktiviert. Ich bin mir nicht sicher, ob das Problem dadurch behoben wird oder ob es nur erneut angezeigt wird und ein anderes Thema auflistet.
Nick
1

Wir haben seit Wochen das gleiche Problem mit verschiedenen Magento CE-Websites. Keiner der hier veröffentlichten Vorschläge hat jedoch geholfen. Nach mehreren frustrierenden Debug-Sitzungen über mehrere Wochen haben wir es endlich geschafft, dies festzuhalten.

Zusammenfassend haben wir festgestellt, dass das Problem auf eine Kombination des SUPEE-6788-Patches Magento <1.9.2.0 und PHP> = 5.5.22 zurückzuführen ist, bei der potenzielle Angreifer oder sogar Sicherheitsscanner die Websites bei Bedarf entfernen können. Wir haben alle Details, einschließlich eines Fixes, in unserem Blog veröffentlicht . Ich hoffe wirklich, dass dies allen anderen armen Seelen hilft, die unter dem gleichen Problem leiden.

mustdobetter
quelle
0

Dieses Problem und unsere Websites treten seit der Veröffentlichung von SUPEE6788 auf, und es scheint, dass betrügerische Aufrufe von xmlrpc-Webservices für die Beschädigung des Caches verantwortlich sein könnten.

Wir blockieren Webservice-Anrufe von unseren Frontservern, da wir sie nicht verwenden. Wenn wir SUPEE 4755 anwenden, halte ich Sie auf dem Laufenden.

Zertrümmert
quelle
Dieser Patch hat die XML-Validierung so geändert, dass sie libxml_disable_entity_loadernicht threadsicher ist. In einigen Fällen kann dies dazu führen, dass Magento zur Installationsseite umleitet. Ich glaube jedoch, dass es vor solchen Fehlern auch möglich ist, den loadDB-Schritt der Konfigurationsgenerierung zu verpassen und beschädigte Daten im Cache zu speichern. Siehe magento.stackexchange.com/questions/30071/…
Luke Rodgers