Мой корень сайта nginx указывает на символическую ссылку. Если я изменяю символическую ссылку (ака развертывание новой версии сайта), старая версия php-скрипта продолжает появляться. Это пахнет кешем или ошибкой.
Сначала было похоже, что Nginx кэшировал символический каталог, но перезагрузка / перезапуск / убийство и запуск nginx не исправили его, поэтому я перезапустил php5-fpm – это исправить мою проблему.
Но я не хочу перезапускать nginx и / или php5-fpm после развертывания – я хочу знать, почему существует такой кеш (или ошибка) и почему он не работает должным образом.
Полезная информация:
Конфигурация сайта Nginx:
root /home/rob/sandbox/deploy/public/; index index.php index.html index.htm; location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass php; } Конфигурация сервера Nginx (частично, по умолчанию – по умолчанию):
http { sendfile off; upstream php { server unix:/var/run/php5-fpm.sock; } }
Дерево для / home / rob / sandbox:
├── deploy -> web2 ├── web1 │ └── public │ └── index.php (echo ONE) └── web2 └── public └── index.php (echo TWO)
http://localhost/index.php Часть результата из realpath_cache_get()
[/home/rob/sandbox/deploy/public/index.php] => Array ( [key] => 1.4538996210143E+19 [is_dir] => [realpath] => /home/rob/sandbox/web2/public/index.php [expires] => 1383730041 )
Таким образом, это означает, что deploy/public/index.php правильно связан с web2/public/index.php , правильно? Ну, даже с правильными путями в списке realpath_cache, respone все равно ONE.
После rm deploy ln -s web2 deploy Nginx был перезапущен, никакого эффекта. Перезапуск php5-fpm после этого дает ожидаемый ответ «TWO».
Хорошо знать, что рядом с файлами index.php я провел некоторое тестирование с файлами .css и .js. После удаления и повторного создания символической ссылки из / в web1 и web2, nginx ответит правильным содержимым файлов.
Что я пропустил, чего не вижу?
Настройте свой nginx с помощью $ realpath_root. Это должно помочь.
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $realpath_root;
Престижность идет к Виталию Чиркову ( https://stackoverflow.com/a/23904770/219272 ).
Как только я изменил значение realpath_cache_ttl на «2» (это должно исправить), неправильный контент все еще показывался.
После некоторого копания загруженных мод для php-fpm я обнаружил, что opcache запущен и работает. Отключение, которое очистит кешированный realpath, когда ttl закончен.
Я не хочу сильно опускать кеш реального пути ttl, поэтому я соглашусь с перезагрузкой php-fpm, так как это изящно. Я надеюсь, что эта тема и мои ответы помогут другим;)
У меня была точно такая же проблема, и ни одна из трюков не помогла. Помимо всех трюков, перечисленных на этой странице, я гарантировал, что opcache отключен, тогда кеш nginx также был отключен. Я установил
sendfile off;
Он был описан где-то в stackoverflow.
Я начал трассировать php и nginx, и выяснилось, что некоторые библиотеки читаются в новом местоположении, а некоторые из них были прочитаны из OLD-адреса, на который symlink больше не указывает. Кроме того, обновление php-скрипта внутри OLD-каталога всегда показывалось правильно – так что это не выглядело как кеш для меня. Чтобы сделать его более запутанной, командная строка отлично работала и следила за символической ссылкой в NEW. Я вытягивал из головы волосы из-за этого!
Оказалось, что ответственным за все это был кеш композитора – он кэшировал некоторые библиотеки. Я знаю, что не все используют его, но если вы это сделаете и имеете подобную проблему, стоит проверить. У меня есть поставщик на том же уровне, что и сценарии развертывания, и я предполагаю, что кеш композитора вызывает много путаницы, какое место следует использовать. После очистки
composer clear-cache
Система начала вести себя так, как ожидалось.
Надеюсь, это поможет кому-то.