SUPEE-6788（可能性あり）キャッシュの問題

SUPEE-6788パッチをクライアントのサイトに適用して以来、1日に1回ほどサイトがダウンし、キャッシュをクリアすることのみがサイトを回復させているようです。ログを確認したところ、ログの多くには「フロントコントローラーが100回のルーターマッチの反復に達した」ことが含まれているようです。この問題は、パッチが適用される前は発生していませんでした。誰もがこれを引き起こしているかもしれない考えを持っていますか？一部の人は、それがmagentoの問題のキャッシュバグである可能性があると言いますが、私にはわかりません。どんな入力でも役に立ちます！

追加のメモ：

• サーバーがダウンしたときにサーバーに大きな負荷がかかっていないので、それは要因ではありません。
• はい、以前のパッチはすべて正常に適用されました。
• キャッシュの保存にはmemcacheを使用しています。

私と別の開発者が同様の問題を経験していますが、このGitHubにあるパッチを適用することで解決したようです：https : //github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

原因は、あるプロセスによってキャッシュがクリアされ、別のプロセスによってキャッシュが再インスタンス化される、ある種の競合状態であると思われます。GitHubにも記載されている手順に従って、キャッシュを再現できました。

この問題についてMagentoでサポートチケットを開きましたが、パッチ以降に何が原因で発生したのか疑っていますが、ご連絡をお待ちしています。

詳細については、スタイルのないページの問題、パスの誤り、SUPEE-6788パッチ適用後のレイアウト構成の損失に関する質問をご覧ください。

3つのサイトバージョン1.8.1でも同じ問題が発生します。これはSUPEE 6788以降に表示され始めました。上記の修正で問題は解決しませんでした。実際、多少の変化はあるようです。修正前は、サイトが1日に2回クラッシュしていましたが、最後のクラッシュは2日後です。しかし、それは負荷に関連している可能性があります。3つのサイトは小さく、負荷はそれほど高くありません。この問題は、バージョン1.6.2でSUPEE 6788が適用されている大きなサイトでは発生しません。すべてのサイトは同じサーバー上にあります-バージョン3.8.1の3つとバージョン1.6.2の大きなサイト

サイトキャッシュをmemcacheからRedisに切り替えてから、12時間ごとにキャッシュをダンプするcronjobを追加しました。1日1回のクラッシュから、再びダウンするまでに約4〜5日かかりました。その後、6時間ごとにダンプするようにcronjobを微調整しましたが、それ以降、ダウンしていません（約3〜4日経過しています）。私たちもホスティング会社も実際の問題を追跡することはできませんが、これは私たちにとって有効な解決策のようです。それが誰かを助けることを願っています。

今朝、AmpersandHQデバッグコードを追加しましたが、たった今、「フロントコントローラーが100回のルーターマッチの反復に達しました」という例外が2分間に約75回発生しました。しかし今回は、おそらくデバッグコードが破損したキャッシュエントリを保存していないため、サイトはまだ起動しており、例外は発生しません（キャッシュをフラッシュしませんでした）。

私はまだこれを調べて調査していませんが、corrupt-cache.logには以下が含まれています：

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}

これは、Magento 1.7.0.2上にあり、RedisキャッシュとAmpersandHQのSUPEE-4755パッチがすでに適用されています。

2015年12月2日更新：完全なスタックトレースの別のエラーを次に示します。

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

さまざまなMagento CE Webサイトで同じ問題が数週間発生しています。ただし、ここに掲載されている提案はどれも役に立ちませんでした。数週間にわたる苛立たしいデバッグセッションを数回行った後、ようやくこれを突き止めることができました。

要約すると、問題はSUPEE-6788パッチ、Magento <1.9.2.0およびPHP> = 5.5.22の組み合わせによるものであり、潜在的な攻撃者またはセキュリティスキャナーでさえ、オンデマンドでサイトをダウンさせることができることがわかりました。修正を含む詳細をブログに投稿しました。私はこれが同じ問題で苦しんでいる他の貧しい魂を助けることを本当に望みます。

SUPEE6788のリリース以降、この問題とWebサイトが発生しており、xmlrpc webservicesへの不正な呼び出しがキャッシュ破損の原因であると思われます。

フロントサーバーからのWebサービス呼び出しは使用していないためブロックします+ SUPEE 4755を適用しますので、引き続きお知らせします。