|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67141 PHP FPM vhost pollution
Submitted: 2014-04-28 10:45 UTC Modified: -
Avg. Score:4.8 ± 0.6
Reproduced:20 of 20 (100.0%)
Same Version:7 (35.0%)
Same OS:7 (35.0%)
From: power2all at gmail dot com Assigned:
Status: Open Package: FPM related
PHP Version: 5.5.11 OS: ubuntu 14.04
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: power2all at gmail dot com
New email:
PHP Version: OS:


 [2014-04-28 10:45 UTC] power2all at gmail dot com
PHP Version: 5.5.9-1ubuntu4 (Ubuntu 14.04 apt version)

When using 1 master process and multiple pool processes, when using chroot and prefix options, the pools individually will pollute each other.
A website with phpBB3 will eventually read out a website with wordpress in between.
A possible inter-exchange of variables might occure, or something similar.

For example:
PHP message: PHP Fatal error:  require_once(): Failed opening required '/public_html/wp-includes/pomo/mo.php' (include_path='.:/usr/share/php:/usr/share/pear') in /public_html/wp-includes/load.php on line 731" while reading response header from upstream, client:, server:, request: "GET / HTTP/1.0", upstream: "fastcgi://", host: ""

This site runs phpBB3 and not Wordpress.
When you refresh the website, sometimes it loads fine, and sometimes it doesn't.

Even with all modules disabled, it does this problem.

Here my configurations:

I made some changes as to apply this:
prefix = /home/anirena
chroot = $prefix
chdir = /

The fastcgi_params file has a small modification to allow it to load properly chrooted content.
Site does load, but with  multiple pools, it gets polluted.

Expected result:
Only work-around right now, is having multiple master processes with 1 pool linked to it.
This ain't a good fix, but it works for now, until the pool pollution issue is found and fixed, or if I made a configuration error.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-02-11 23:20 UTC] public+php dot net at bastelstu dot be
Did you try setting 'opcache.revalidate_freq=0'? Forcing opcache to revalidate the file on every request circumvented the issue for me.

But I agree that this should be fixed in opcache (e.g. by including the inode or the fpm pool name)
 [2016-09-08 10:41 UTC] mustang at gmail dot com
Just hit this nasty.

"opcache.revalidate_freq=0" does seem to be working for now (only tested briefly), although it's not really a very good solution.

I saw mention in #72521 that a cache prefix would probably work, how could I set this up? Or does such a feature not exist yet.

Would be nice if this could be looked into as per user pools are basically useless at the moment.
 [2017-10-20 14:39 UTC] nicolas dot girardet at gmail dot com
Same issue with the following configuration:
PHP Version: 7.1.10
OS: Debian 4.9.30
Apache: 2.4.24
 [2020-02-13 11:20 UTC] mustang at miswave dot com
From 5.6.29, 7.0.14, and 7.1.0 looks like this can now be solved with:
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Feb 05 12:05:47 2023 UTC