PHP обслуживает неправильные страницы с Laravel
У меня абсурдная проблема.
Я использую Laravel в одном из своих проектов. Я был в Laravel v5.2.39 (и большинство пакетов Symfony были на v3.0.8 , если это актуально), и все работало нормально. После обновления (с composer update ) до Laravel v5.2.45 я столкнулся с очень странной проблемой, заключающейся в том, что PHP смешивал страницы и обслуживал неправильные.
Перезапуск PHP-FPM решает проблему до тех пор, пока я не попаду на страницу своего сайта Laravel, после чего PHP начнет сходить с ума и беспорядочно обслуживать пустые страницы, неправильные страницы с того же сайта или страницы с других сайтов.
Это не так. происходит только внутри моего проекта Laravel, но похоже, что это происходит со всеми веб-сайтами на том же Apache VirtualHost. Например, Иногда я получаю обслуживаемые страницы с оскорбительного веб-сайта Laravel при посещении другой (несвязанной) страницы PHP на том же VirtualHost, но также и других (не связанных) страниц PHP. Но я получаю только обслуживаемые страницы, которые обслуживались раньше, а не новые (непосещенные) страницы.
Так что, я думаю, это странная проблема, связанная с кешированием? Я попытался внести этот веб-сайт Laravel в черный список из PHP OPCache, но это не решило проблему.
Я точно знаю, что это как-то связано с более новой версией Laravel (или новой версией одной из зависимостей Laravel), потому что проблема в исчезнет, если я переустановлю старую версию, и проблема появится снова после обновления композитора .
Информация о сервере:
Но я получаю только обслуживаемые страницы, которые обслуживались раньше, а не новые (непосещенные) страницы.
Итак, я думаю, это странная проблема, связанная с кешированием? Я попытался внести этот веб-сайт Laravel в черный список из PHP OPCache, но это не решило проблему.
Я точно знаю, что это как-то связано с более новой версией Laravel (или новой версией одной из зависимостей Laravel), потому что проблема в исчезнет, если я переустановлю старую версию, и проблема появится снова после обновления композитора .
Информация о сервере:
Но я получаю только обслуживаемые страницы, которые обслуживались раньше, а не новые (непосещенные) страницы.
Итак, я думаю, это странная проблема, связанная с кешированием? Я попытался внести этот веб-сайт Laravel в черный список из PHP OPCache, но это не решило проблему.
Я точно знаю, что это как-то связано с более новой версией Laravel (или новой версией одной из зависимостей Laravel), потому что проблема в исчезнет, если я переустановлю старую версию, и проблема появится снова после обновления композитора .
Информация о сервере:
ОС: Debian Stretch
Веб-сервер: Apache / 2.4.23
PHP-FPM: 7.0.10-1
Интересно, что я знаю друга, у которого недавно была точно такая же проблема. Я думаю, что в итоге он использовал mod-php вместо PHP-FPM.
РЕДАКТИРОВАТЬ:
Итак, после того, как я все еще сталкивался с этой проблемой после выпуска обновления композитора в моем проекте, я решил далее исследуйте это, обновляя каждый пакет один за другим. Таким образом, мне удалось сузить проблему до обновления symfony / http-foundation с версии v3.0.8 до v3.0.9 .
Итак это не обновление Laravel, которое вызывает проблемы, а обновление одной из его зависимостей.
Я понятия не имею, как действовать дальше.
Оказалось, что у меня есть идея, как действовать дальше.
Прочитав журнал изменений Symfony для версии 3.0.9, я увидел коммит относительно fastcgi_finish_request(). Я читал в docs, что эта функция может иметь некоторые подводные камни при использовании с PHP-FPM. Интересно. Может ли это быть связано?
Чтобы узнать, действительно ли мои процессы PHP-FPM достигли pm.max_children, я включил страницу состояния PHP-FPM. Даже без сайта Laravel я заметил, что некоторые потоки, похоже, застряли в состоянии finished. Это неправильно...
Оказалось, что это было вызвано конфигурацией Apache, которую я использовал для подключения Apache к PHP-FPM:
<Proxy "unix:/run/php/php7.0-fpm.sock|fcgi://php-fpm">
# we must declare a parameter in here or it'll not register the proxy ahead of time
ProxySet disablereuse=on
</Proxy>
<FilesMatch \.php$>
SetHandler proxy:fcgi://php-fpm
</FilesMatch>
что более или менее необходимо для взлома, чтобы заставить его работать с UDS путями в более ранние дни. Похоже, что это больше не требуется и привело к зависанию процессов PHP-FPM в состоянии finished, так как эта проблема была решена, когда я удалил её и включил удобно предоставленный конфиг в conf-available/php7. Вместо этого в [0-fpm.conf.
После обновления пакета Symfony до версии 3.0.9 проблема не вернулась.
Это, наверное, самая странная проблема, связанная с сервером, которую я видел и решал, и я до сих пор не до конца понимаю, что происходило. Но она решена.