php.net |  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: 2023-09-17 15:50 UTC
Votes:22
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: bukka (profile)
Status: Assigned Package: FPM related
PHP Version: 5.5.11 OS: ubuntu 14.04
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

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

Description:
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: 80.82.71.7, server: anirena.com, request: "GET / HTTP/1.0", upstream: "fastcgi://127.0.0.1:5002", host: "www.anirena.com"

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:
http://p.ngx.cc/84c66229a899aae5

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.



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

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:
opcache.validate_root=1
 [2023-09-17 15:50 UTC] bukka@php.net
I have had a look on this and think this is primarily because the opache shared memory is also shared between pools - I think the optimal solution would be to introduce a pool manager as suggested in https://github.com/php/php-src/issues/11723 . Then we could make sure that things work as they should.

In terms of tagging, it would have to somehow get that info from the pool or do it per child but that would not be really effective. Passing pool info would require some extra info / API. There are however other issues (specially when different pool users / groups are configured) so it would be better to separate it completely so might not be worth to spend time on that.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 03:01:29 2024 UTC