SUPEE-6788 (Mögliche) Cache-Probleme

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.

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 .

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

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.

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')

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.

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.