SUPEE-6788 (Possibili) Problemi di cache

Da quando abbiamo applicato la patch SUPEE-6788 sul sito di un client, circa una volta al giorno il sito è andato in crash e l'unica cosa che sembra riportarlo è svuotare la cache. Abbiamo esaminato i registri e alcuni di essi sembrano includere "Il controller anteriore ha raggiunto 100 iterazioni di corrispondenza router". Questo problema non si verificava prima dell'applicazione della patch. Qualcuno ha idea di cosa potrebbe causare questo? Alcune persone dicono che potrebbe essere un bug di cache nel problema di Magento, ma non posso dirlo. Qualsiasi input sarebbe utile!

Alcune note aggiuntive:

• Non ci sono stati carichi pesanti sul server proprio quando si è spento, quindi non è un fattore.
• Sì, tutte le patch precedenti sono state applicate correttamente.
• Stiamo usando memcache per memorizzare la cache.

Io e un altro sviluppatore abbiamo riscontrato un problema simile, tuttavia sembra che l'abbiamo risolto applicando la patch presente in questo GitHub: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

La causa sembra essere una sorta di race condition in cui la cache viene cancellata da un processo mentre viene ri-istanziata da un altro, sono stato in grado di riprodurlo seguendo i passaggi elencati anche su quel GitHub.

Ho aperto un ticket di supporto con Magento per questo problema e ho i miei sospetti su ciò che ha iniziato a causarlo dopo la patch, ma sono in attesa di risposta.

Puoi leggere ulteriori informazioni al riguardo sulla seguente domanda: Problemi con la pagina non stilata, Percorsi errati, perdita della configurazione del layout dopo l'applicazione della patch SUPEE-6788 .

Abbiamo lo stesso problema con 3 siti versione 1.8.1. Ha iniziato ad apparire dopo SUPEE 6788. La correzione dall'alto non ha risolto il problema. In realtà, sembra che ci siano dei cambiamenti. Prima della correzione i siti si arrestavano in modo anomalo due volte al giorno, ora l'ultimo incidente si verificava dopo 2 giorni. Ma potrebbe essere legato al carico. I 3 siti sono piccoli e non molto caricati. Questo problema non si presenta con un sito di grandi dimensioni con la versione 1.6.2 e SUPEE 6788 applicati. Tutti i siti si trovano sullo stesso server: il 3 con la versione 1.8.1 e quello grande con la versione 1.6.2

Abbiamo fatto passare la cache del sito da memcache a Redis e quindi aggiunto un cronjob per scaricare la cache ogni 12 ore. Passava dal crash una volta al giorno a circa 4-5 giorni prima di scendere di nuovo. Abbiamo quindi modificato il cronjob per scaricare ogni 6 ore e non è diminuito da allora (sono passati circa 3-4 giorni da allora). Né noi né la società di hosting possiamo rintracciare il problema reale, ma questa sembra essere una soluzione funzionante per noi. Spero che aiuti qualcuno.

Ho aggiunto il codice di debug AmpersandHQ questa mattina e proprio ora l'eccezione "Front controller ha raggiunto 100 iterazioni di corrispondenza router" si è verificata circa 75 volte in un periodo di 2 minuti. Ma questa volta, presumibilmente a causa del codice di debug che non salva la voce della cache corrotta, il sito è ancora attivo senza che tutti ricevano eccezioni (non ho scaricato la cache).

Non ho ancora scavato in questo per indagare, ma corrotti-cache.log contiene:

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}

Questo è su Magento 1.7.0.2 con la cache Redis e la patch SUPEE-4755 di AmpersandHQ già applicate.

Aggiornamento del 2 dicembre 2015: ecco un altro errore con la traccia dello stack completo:

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

Abbiamo riscontrato lo stesso problema da settimane con vari siti Web Magento CE. Tuttavia, nessuno dei suggerimenti pubblicati qui ha aiutato. Dopo diverse frustranti sessioni di debug nel corso di diverse settimane, siamo finalmente riusciti a fissare questo problema.

In sintesi, abbiamo riscontrato che il problema è dovuto a una combinazione della patch SUPEE-6788, Magento <1.9.2.0 e PHP> = 5.5.22, con potenziali aggressori o persino scanner di sicurezza in grado di abbattere i siti su richiesta. Abbiamo pubblicato tutti i dettagli, inclusa una correzione, sul nostro blog . Spero davvero che ciò aiuti tutte le altre povere anime che soffrono dello stesso problema.

Stiamo riscontrando questo problema e i nostri siti Web da quando abbiamo rilasciato SUPEE6788 e sembra che le chiamate fraudolente ai servizi web xmlrpc possano essere responsabili della corruzione della cache.

Stiamo bloccando le chiamate al servizio web dai nostri server front poiché non le usiamo + applicando SUPEE 4755, ti terrò aggiornato.