When I've seen similar issues in our environments, it appears to have been because of the way that OpCache (by default) shares a single cache across all users on a shared hosting environment. A bug has been submitted (and you can, and should, go and vote to let the maintainers know how important this might be for your use case) though no commitment has been made on delivering a fix.
TL;DR : By default when OpCache is enabled, the cache that is used to store compiled byte-code is shared across all users. In an environment where hosting is shared between multiple sites / users, this can result in a site grabbing the cached output of php scripts from another site or, if specific security settings are enabled even generating errors.
If you plan on using PHP-FPM with PHP 5.5+'s built in opcache, please read the blog post below before you actually do that. Turns out that the opcode cache can be read by any user on the server. This means that if there are say, 10 separate users, with their own vhosts and directories, and you configure one PHP-FPM pool per user, each user can still see what scripts are cached and their locations. Since they have read access to the cache they could potentially view all this data.
This is obviously a massive security concern, and even if no one exploits this, there is still a chance of scripts being read by the wrong user when generating a page, so websites could possibly be displaying the wrong data / info if there are multiple index.php scripts in the cache.
Although no fix has been officially released, if you're using cPanel, this wiki has a documented way of configuring the php-fpm pools to be created and secured on a per-user basis and if you follow the instructions below as well as the IMPORTANT NOTES at the bottom of this answer you should be able to get the functionality you desire without any errors
That post also documents how you might configure this by hand on a per-site/per-user basis (though I'd wager that might become tedious if you're hosting a lot of sites). If you're not using cPanel, you may need to modify the scripts to specify your individual paths and usernames instead of the variables being used by cPanel's config engine.
IMPORTANT NOTES
During testing and additional research I came across this article which provide a few clarifications that may be relevant to your specific situation:
- You need to make sure that the
opcache.use_cwd parameter is set to true for your application's configuration of OpCache - it's set to false by default and leaving it set to default will probably cause collisions if you're hosting more than one PHP application on your system:
First of all, probably in each typical project you will have to ensure that the opcache.use_cwd option is set to true. Enabling this setting means that the OpCache engine will look at the full file paths to distinguish between files with the same names. Setting it to false will lead to collisions between files with the same base name.
- If you're running an application powered by Zend Framework or another similar framework that makes use of annotations, you ALSO need to ensure that the
opcache.load_comments and opcache.save_comments directives are set to true. You should double-check this suggestion with your application / framework documentation as most have now updated their docs with specific instructions on enabling the use of OpCache properly for their systems:
There is also a setting that is important in tools and frameworks that make use of annotations. If you use Doctrine, Zend Framework 2 or PHP Unit, remember to set the opcache.load_comments and opcache.save_comments settings to true. In result, the documentation comments from your files will also be included in the precompiled code generated by OpCache. This setting will allow you to work with annotations without any disruptions.
If your project is based on a specific framework or a web application, it’s always a good idea to check the documentation for any guidelines regarding the OpCache configuration
IMPORTANT NOTES
Hopefully this helped - and if you're using cPanel, drop a comment to let us know how you tackled that portion of the configuration! See also this question and associated comments.
