Мой корень сайта 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 ответит правильным содержимым файлов.
Что я пропустил, чего не вижу?
Как только я изменил значение realpath_cache_ttl на "2" (это должно исправить его), пока не отображается неправильный контент.
После некоторого копания загруженных мод для php-fpm я обнаружил, что opcache запущен и работает. Отключение, которое очистит кэшированную реальную траекторию при завершении ttl.
Я не хочу сильно опускать кеш реального кэша ttl, поэтому я соглашусь с перезагрузкой php-fpm, так как это изящно. Я надеюсь, что эта тема и мои ответы помогут другим;)
Настройте свой nginx с помощью $realpath_root. Это должно помочь.
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
Престижность идет к Виталию Чиркову (fooobar.com/questions/238436/...).
У меня была точно такая же проблема, и ни одна из трюков не помогла. Помимо всех трюков, перечисленных на этой странице, я гарантировал, что opcache отключен, тогда кеш nginx также был отключен. Я установил
sendfile off;
Это описано где-то в stackoverflow.
Я начал трассировать php и nginx, и выяснилось, что некоторые библиотеки читаются в новом местоположении, а также некоторые из них были прочитаны из OLD-местоположения, о которых символическая ссылка больше не указывает. Кроме того, обновление PHP скрипт внутри OLD-каталога всегда показывалось правильно - так что это не выглядело как кеш для меня. Чтобы сделать его более запутанной, командная строка отлично работала и следила за символической ссылкой в NEW. Я вытягивал волосы из головы над этим!
Оказалось, что ответственным за все это был кеш композитора - он кэшировал некоторые библиотеки. Я знаю, что не все используют его, но если вы это сделаете и имеете подобную проблему, стоит проверить. У меня есть поставщик на том же уровне, что и сценарии развертывания, и я предполагаю, что кеш композитора вызывает много путаницы, какое место следует использовать. После очистки с помощью
composer clear-cache
Система начала вести себя так, как ожидалось.
Я надеюсь, что это поможет кому-то.