0

I have an absurd problem.

I'm using Laravel for one of my projects. I was at Laravel v5.2.39 (and most Symfony packages were at v3.0.8 if that's relevant) and everything was working fine. After updating (with composer update) to Laravel v5.2.45, I ran into a very strange problem, which is that PHP was mixing up pages and serving the wrong ones.

Restarting PHP-FPM fixes the problem, until I hit a page from my Laravel website, after which PHP starts going crazy and randomly serving blank pages, wrong pages from the same site, or pages from other sites.

This doesn't only happen inside my Laravel project, but it happens to all websites on that same Apache VirtualHost, it seems. For example, I sometimes get served pages from the offending Laravel website when visiting another (unrelated) PHP page on the same VirtualHost, but also other (unrelated) PHP pages. But I only get served pages that were served before, no new (unvisited) pages.

So I guess this is a weird problem related to caching? I tried blacklisting that Laravel website from PHP's OPCache, but that doesn't solve the problem.

I know for sure this is somehow related to the newer Laravel version (or a new version of one of Laravel's dependencies) because the problem is gone if I reinstall the old version, and the problem appears again after a composer update.

Server info:
OS: Debian Stretch
Web server: Apache/2.4.23
PHP-FPM: 7.0.10-1

Interestingly enough, I know a friend who once had the exact same problem a while back. He ended up using mod-php instead of PHP-FPM I think.

EDIT:

So, after still being confronted with this problem after issuing a composer update on my project, I decided to further investigate this by updating every package one by one. This way I managed to narrow down the issue to the update of symfony/http-foundation from version v3.0.8 to v3.0.9.

So it's not an update of Laravel that causes the problems, but an update of one of its dependencies.

I have no idea how to proceed further though.

2
  • Your description makes it sound like a bug in Laravel. Please report the bug first, and then come back here only after you are sure it is not a bug in Laravel. Sep 8, 2016 at 21:14
  • It must be something in PHP. Something in Laravel triggers it, but other websites (non-Laravel) on the same server are affected by it. Once it has been triggered, this problem occurs with every PHP page I try to access. For example, let's say a server runs 10 websites (A, B, C, etc). Website A is the offending Laravel site. After the problem has been triggered by accessing a page from website A, now I get served pages from website D and E (for example) when accessing website B. This should never happen of course, no matter how buggy Laravel is.
    – Compizfox
    Sep 8, 2016 at 22:21

1 Answer 1

0

It turned out I did have an idea how to proceed.

Reading through Symfony's changelog for 3.0.9, a commit regarding fastcgi_finish_request() caught my eye. I read at the PHP docs that this function can have some pitfalls when used with PHP-FPM. Interesting. Could this be related?

To investigate whether my PHP-FPM processes had indeed reached pm.max_children, I enabled the PHP-FPM status page. Even without the Laravel site, I noticed that some threads seemed to be stuck in the finished state. That's not right...

It turned out this was caused by the Apache config I used to connect Apache to 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>

which is more or less a hack needed to get it to work with UDS paths in earlier days. It seems this is not longer required and caused PHP-FPM processes to hang in finished state, because this issue was solved when I removed it and enabled the conveniently provided config in conf-available/php7.0-fpm.conf instead.

After updating the Symfony package to 3.0.9 the problem did not return.

This is probably the weirdest server-related problem I've seen and solved, and I still don't fully understand what was going on. But it's solved.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .