Nginx и/или php5-fpm запоминают символическую корневую директорию

Мой корень сайта nginx указывает на символическую ссылку. Если я изменяю символическую ссылку (ака развертывание новой версии сайта), то появляется старая версия PHP скрипт. Это пахнет кешем или ошибкой.

Сначала было похоже, что Nginx кэшировал символический каталог, но перезагрузка/перезапуск/убийство и запуск nginx не исправили его, поэтому я перезапустил php5-fpm - это исправить мою проблему.

Но я не хочу перезапускать nginx и/или php5-fpm после развертывания - я хочу знать, почему существует такой кеш (или ошибка) и почему он не работает должным образом.

Полезная информация:

ОС: Ubuntu 13.10 (GNU/Linux 3.8.0-19-generic x86_64)
Nginx: через ppa: nginx/stable
PHP: через ppa: ondrej/php5 (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
ожидаемый ответ: TWOli >
фактический ответ: ONE

Часть выхода из 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 ответит правильным содержимым файлов.

Что я пропустил, чего не вижу?

Ответ 1

Как только я изменил значение realpath_cache_ttl на "2" (это должно исправить его), пока не отображается неправильный контент.

После некоторого копания загруженных мод для php-fpm я обнаружил, что opcache запущен и работает. Отключение, которое очистит кэшированную реальную траекторию при завершении ttl.

Я не хочу сильно опускать кеш реального кэша ttl, поэтому я соглашусь с перезагрузкой php-fpm, так как это изящно. Я надеюсь, что эта тема и мои ответы помогут другим;)

Ответ 2

Настройте свой nginx с помощью $realpath_root. Это должно помочь.

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;

Престижность идет к Виталию Чиркову (fooobar.com/questions/238436/...).

Ответ 3

У меня была точно такая же проблема, и ни одна из трюков не помогла. Помимо всех трюков, перечисленных на этой странице, я гарантировал, что opcache отключен, тогда кеш nginx также был отключен. Я установил

sendfile off;

Это описано где-то в stackoverflow.

Я начал трассировать php и nginx, и выяснилось, что некоторые библиотеки читаются в новом местоположении, а также некоторые из них были прочитаны из OLD-местоположения, о которых символическая ссылка больше не указывает. Кроме того, обновление PHP скрипт внутри OLD-каталога всегда показывалось правильно - так что это не выглядело как кеш для меня. Чтобы сделать его более запутанной, командная строка отлично работала и следила за символической ссылкой в NEW. Я вытягивал волосы из головы над этим!

Оказалось, что ответственным за все это был кеш композитора - он кэшировал некоторые библиотеки. Я знаю, что не все используют его, но если вы это сделаете и имеете подобную проблему, стоит проверить. У меня есть поставщик на том же уровне, что и сценарии развертывания, и я предполагаю, что кеш композитора вызывает много путаницы, какое место следует использовать. После очистки с помощью

composer clear-cache

Система начала вести себя так, как ожидалось.

Я надеюсь, что это поможет кому-то.