4

それは明らかなことだと確信していますが、私はここでかなり立ち往生しています。問題なく動作しているLAMPサーバー(Centos 5.3、PHP 5.3.8)があります。特定の PHP スクリプトを変更して (SFTP 経由で) サーバーに再アップロードしましたが、ページをリロードすると古いスクリプトがまだ実行されています。新しいファイルがそこにあり、タイムスタンプとサイズが新しいバージョンと一致していることがわかりますが、常にファイルが変更されていないかのように出力されます。シンプルなものに置き換えてみました

<?php die('test'); ?> 

テストファイル、同じ結果。これはブラウザーのキャッシュの問題ではありません (リロード、さまざまなブラウザーなどはすべて古いスクリプトを表示し、$_GET変数を渡すことができ、古いスクリプトとして実行されます)。ファイルの名前を変更すると、新しい名前で (新しい変更で) 正しくレンダリングされ、システムは元の場所で 404 エラーを正しくスローします。元のファイル名に戻すと、古いバージョンとしてのレンダリングに戻ります。私はそれがe-acceleratorの問題(0.9.6.1を実行している)だと考えたので、キャッシュをクリアし(空に/var/cache/php-eacceleratorしました)、サーバーを再起動しましたが、サイコロはありませんでした。

サーバーが古いスクリプトをキャッシュする原因となっているものは他にありますか?

編集 - 解決策!

OK、当然のことながら、これはアプリケーション固有の問題であり、もっと早く解決する必要がありました。/custom/アプリケーションは、問題の原因となった「カスタムオーバーライド」システムでセットアップされました...基本的に更新を簡単にするだけでなく、クライアントによるカスタマイズも可能にするために、システムは、アプリケーションのフォルダー構造を複製する特別なフォルダーでセットアップされましたベースアプリケーション。サービスを提供する前に、Apache は明らかにカスタム構造内に同じ場所にあるファイルをチェックし、存在する場合は代わりにそれを提供します。基本的に、関連するディレクトリにアップロードされたカスタム スクリプトがあり、メイン アプリケーション ディレクトリにアップロードしたファイルを上書きしていました。どうやら、カスタム ディレクトリにオーバーライド スクリプトがロードされていたようです。

@Dagon、eAcceleratorを無効にする提案をありがとう。私はそれが私の問題の原因であると確信していたので、わざわざチェックすることはしませんでした.htaccess. それを除外すると、私はより明確に考え始めました。

4

1 に答える 1

2

これは最終的にローカライズされた問題になりました。質問の編集で述べたように、アプリケーションは問題の原因となっている「カスタムオーバーライド」システムでセットアップされました...基本的に更新を簡単にするだけでなく、クライアントによるカスタマイズも可能にするために、システムは次のようにセットアップされましたベース アプリケーションのフォルダー構造を複製する特別な /custom/ フォルダー。サービスを提供する前に、Apache は明らかにカスタム構造内に同じ場所にあるファイルをチェックし、存在する場合は代わりにそれを提供します。基本的に、関連するディレクトリにアップロードされたカスタム スクリプトがあり、メイン アプリケーション ディレクトリにアップロードしたファイルを上書きしていました。どうやら、カスタム ディレクトリにオーバーライド スクリプトがロードされていたようです。

于 2012-09-19T06:37:34.570 に答える