PHP-FPM Directory Index index.html file not found problem
I've been setting up FPM using the tutorial for EA4 and for the most part it's working with straight PHP sites, but sites with mixed content (index.html) have a problem.
My fpm.conf files following this pattern:
From what I've read, the above looks for .php files and if it's a directory index returns index.php. The problem is apache doesn't pass the full path here so a folder like /foldername/ that normally loads /foldername/index.html tries to load /foldername/index.php instead even though it doesn't exist. Loading /foldername/index.html directly works. I tried adding other index.html, etc. names to the DirectoryIndex here but no difference. This is the method from the tutorial so cPanel may not be aware of this problem yet. Anyone have any ideas that can be done at the configuration level instead of site htaccess changes / filename changes? Anyway to know that the directoryindex is index.html before the proxy kicks in?
ProxyPassMatch "^/(.*\.php(/.*)?)$" "unix:/home/username/run/php56-fpm.sock|fcgi://localhost/home/username/public_html"
DirectoryIndex index.php
From what I've read, the above looks for .php files and if it's a directory index returns index.php. The problem is apache doesn't pass the full path here so a folder like /foldername/ that normally loads /foldername/index.html tries to load /foldername/index.php instead even though it doesn't exist. Loading /foldername/index.html directly works. I tried adding other index.html, etc. names to the DirectoryIndex here but no difference. This is the method from the tutorial so cPanel may not be aware of this problem yet. Anyone have any ideas that can be done at the configuration level instead of site htaccess changes / filename changes? Anyway to know that the directoryindex is index.html before the proxy kicks in?
-
It seems to break FancyIndexing as well. 0 -
I am finding it works better if I place an index.html before index.php, but FancyIndexing still doesn't work. ProxyPassMatch "^/(.*\.php(/.*)?)$" "unix:/home/username/run/php56-fpm.sock|fcgi://localhost/home/username/public_html" DirectoryIndex index.html index.php
I'm also looking into using SetHandler instead of ProxyPassMatch as recommended here: PHP-FPM and HTTPD 2.4 improvement - Remi's RPM repository - Blog ...but not much luck there. I end up getting indexes and html to work but php breaks.0 -
Does: SetHandler "proxy:unix:/home/%user%/run/php56-fpm.sock|fcgi://localhost" ProxyErrorOverride on
Not work? This seems to work for me.0 -
SetHandler "proxy:unix:/home/%user%/run/php56-fpm.sock|fcgi://localhost" ProxyErrorOverride on
That works great. Thank you very much. When I tried SetHandler before, I used the full "localhost/home/username/public_html" as in the tutorial, but it looks like that doesn't work on SetHandler and needs to be trimmed to how you provided. This also solved a number of other issues i was researching in addition to the html indexing and FancyIndexes problem, such as seeing apache error messsages and problems with Wordpress Multisite not loading some pages. All looks good now. cPanel, you should revise your tutorial (linked below) to indicate that people running Apache 2.4.10 and above should use the this method instead since it appears to be much more compatible. Tutorial: Configure PHP-FPM with User Pools for EasyApache 4 - cPanel Knowledge Base - cPanel Documentation0 -
The Apache error is now displayable because of the ProxyErrorOverride on Are you still having issues with FancyIndexing? That would appear to be more of a general Apache issue and unrelated to PHP-FPM I am also curious as to why DirectoryIndex is being included in the userdata file for each VirtualHost (as per the cPanel docs). Am I missing a reason for why that should be there? 0 -
When they use ProxyPassMatch the directory index of the server no longer appears to work, so they added back index.php so those would work. FancyIndexing is now fine. Basically only a minor use case for a few folders where I needed people to see files. Normally auto indexing is off. Interesting thing about the ProxyErrorOverride. I had to disable that because every 404 was returning an Error 500 instead and in one case a wordpress plugin was causing me to use up all my pools and then lock out further connections simply becuase there was a stylesheet in the plugin referring to iamges that didn't exist and I guess some kind of plugin check for wordpress would trigger it. Basically I just log into wordpress dashboard and immediately watch the pools grow to the limit. Weird. So, after deleting ProxyErrorOverride, I still see the correct error messages so it seems fine without it. Perhaps that was more important with the ProxyPassMatch method. 0 -
Hello :) The "Configure PHP-FPM with User Pools for EasyApache 4" document is still a work in-progress. It looks like some tweaks to this document are planned and under review at this time. Could you provide a list of any items that still require an update on this document, and we can report them to our documentation team? Thank you. 0 -
Here's a variety of things I came across while implementing the tutorial, researching online and referring to posts made by other cPanel users who had already gone down this path. " Either replace Step 6b"s code with the following or indicate that Apache 2.4.10+ users should use this code instead for better compatibility. SetHandler "proxy:unix:/home/$/run/php56-fpm.sock|fcgi://localhost"
" Step 6b might also mention that the fpm.conf can be placed in the folder to set a default PHP-FPM config for all domains for that user account. fpm.con files placed in / as directly would still override the default for the useraccount. This just speeds up the manual configuration process when setting up a bunch of accounts. " Step 2 should also indicate to create a session foldermkdir -p /home/$/tmp/session
"or another folder if cPanel prefers something different. The sessions need a user-owned folder to write. " Step 4f Change the Session save path to the folder created above.php_value[session.save_path] = /home/$/tmp/session
" After Step 4d I"d recommend either mentioning the following setting or recommending it especially for servers with a lot of accounts so that initial memory consumption is a lot less before more advanced configuration is made. The "dynamic" default launches a minimum of 1 pool per user, while "on demand" only launches the pools as needs and sticks around for the amount of time set by "pm.process_idle_timeout". Previous FCGID users should find these options similar.pm = ondemand
Some in general notes... " The php.ini"s as configured within WHM do not apply and must be manually configured at the following locations. These are individually set per PHP version./opt/cpanel/ea-php56/root/etc/php.ini /opt/cpanel/ea-php55/root/etc/php.ini /opt/cpanel/ea-php70/root/etc/php.ini
" If you want to make use of the OPCache ini to activate and configure, go here:/opt/cpanel/ea-php56/root/etc/php.d/opcache.ini /opt/cpanel/ea-php55/root/etc/php.d/opcache.ini /opt/cpanel/ea-php70/root/etc/php.d/opcache.ini
" Right now as instructed the OPCache is shared amongst all sites running the same version of PHP. You may want to move in the direction of setting up master processes per user so the OPCache is only shared amongst each user account alone. This would be a much more complex config but likely more secure. Reloading or Restarting the FPM Master processes would be more difficult as well, but I"m sure a script could facilitate that once FPM is integrated into EasyApache. " Some script options to be aware of as shown in Step 5. If you"ve made changes to the conf files you can do a Reload to apply those changes. This waits for current pool processes to complete before reloading. This resets the OPCache as well./etc/init.d/ea-php70-php-fpm reload /etc/init.d/ea-php55-php-fpm reload /etc/init.d/ea-php70-php-fpm reload
If you"ve made changes to the main php.ini files you need to do a Restart to apply those changes. This also applies the conf changes and OPCache reset./etc/init.d/ea-php70-php-fpm restart /etc/init.d/ea-php55-php-fpm restart /etc/init.d/ea-php70-php-fpm restart
" I also noticed that the WHM / cPanel interface for creating the user"s php.ini file creates a php.ini file as expected, but the main php.ini for each version of PHP is not actually configured to use it so it doesn"t work by default. Setting the following fixes that.user_ini.filename = "php.ini"
" Also since FPM currently required manually configuration for changes, I looked to disable the MultiPHP Manager in the Feature Manager while keeping the MultiPHP INI Editor active, but unfortunately disabling MultiPHP Manager disables both sections from appearing. This will be moot once FPM is fully integrated.0 -
Hello :) Thank you taking the time to formulate that response. There's a new internal case open (HB-1471) that aims to explore using PHP-FPM in several different environments that would address these types of issues. There's no specific time frame to provide on when it might get implemented, but I'll update this thread once more information is available. Thank you. 0 -
Hello :) Thank you taking the time to formulate that response. There's a new internal case open (HB-1471) that aims to explore using PHP-FPM in several different environments that would address these types of issues. There's no specific time frame to provide on when it might get implemented, but I'll update this thread once more information is available. Thank you.
I can confirm, majority of the above advice is correct. `SetHandler` is the way to go, first of all. And you shouldn't append additional path items to the proxy definitions, because it will throw off the DocumentRoot calculation. Speed improvements going to PHP7 + FastCGI are massive. A PHP7 page building in 0.80s before now builds consistently in 0.15s, similar to what I'm seeing on my fully optimize Gentoo staging site. Compared to PHP5, it's even more - possible a 10x+ raw build speed improvement. EDIT another optimization is to use php-fpm's built-in $pool variable for $.conf, instead of repeating hardcoded username everywhere. This also paves way for better automating. EDIT slowlog parameter path value should be adjusted to /home/$/logs0 -
Configure PHP-FPM with User Pools for EasyApache 4 - cPanel Knowledge Base - cPanel Documentation [LIST] - represents the name of a user on the system.
- example.com represents the domain's base directory.
- represents the user's account.
- represents the name of the virtual host. What is the difference between and ? And example.com and ? it's a bit confusing since both values looks the same Testing in PHP-FPM, MPM-event in EA4 PHP56 Centos 6.7 cPanel 56.x for few sites first
0 -
Cool, I start testing it today. Maybe you can help me a bit with this part of the documentation. Documentation doubt about Configure PHP-FPM with User Pools for EasyApache 4 0 -
"/scripts/restartsrv_cpanel_php_fpm" is just for restarting the cpanel services php-fpm and not php-fpm for user sites. You may find some of my experience useful from this thread (especially toward the end): PHP-FPM Directory Index index.html file not found problem 0 -
Thanks, actually I was reading that thread, but /scripts/restartsrv_cpanel_php_fpm" is just for restarting the cpanel services php-fpm and not php-fpm for user sites.
help me to figure out a problem with exim also thanks!0 -
Hello, You can follow the progress of enhanced FPM support referenced in my previous post at: Enhance FPM support It's tentatively scheduled for the version 58 release cycle. Please feel free to add feedback to this feature request. Thank you. 0 -
Just discovered another issue when I rebooted, the user PHP-FPM processes weren't starting under Centos 6.7. Looks like the /etc/rc.d runlevels for the php-fpm scripts were not created correctly and every runlevel was set to kill the process even for startups. K16ea-php54-php-fpm K16ea-php55-php-fpm K16ea-php56-php-fpm K16ea-php70-php-fpm So for the startup runlevels (rc2.d, rc3.d, rc4.d, rc5.d) it looks like I needed to change them to: S16ea-php54-php-fpm S16ea-php55-php-fpm S16ea-php56-php-fpm S16ea-php70-php-fpm I'll see if it works the next time I need to reboot for a kernel update. 0 -
One issue I seem to have found with using: SetHandler "proxy:unix:/home/$/run/php56-fpm.sock|fcgi://localhost"
Is that there is a long delay in processing a file not found. If you set this and then try to vist: [plain]http://example.tld/filethatdontexist.php[/plain] It takes about 15 seconds for the 404 to generate. It has to be a timeout issue in the proxy system, but I don't exactly know how to overwrite that. Or where you might do that. Is anybody else seeing the same thing? Any suggested fixes?0 -
Actually what I had was SetHandler "proxy:unix:/home/$/run/php56-fpm.sock|fcgi://localhost" ProxyErrorOverride on
On a WordPress site. Apparently some combination of WordPress's file not found .htaccess code and ProxyErrorOverride on causes significant delays.0 -
Yeah, if you'll note above I removed ProxyErrorOverride On because it turned my 404s into Error 500s. Seems to work great without it and I don't see any 404 delay. 0 -
Agreed. Kudos on your post, by the way. I was thinking that what I had set and what you had in your post were the same thing. But after I looked at it closer I saw that you had removed ProxyErrorOverride On in your post and when I did the same with my settings, the problem was resolved. Lesson learned, I should pay closer attention to what I have set. 0 -
I have just tried to set up php-fpm following all the instructions that are made here: Configure PHP-FPM with User Pools for EasyApache 4 - cPanel Knowledge Base - cPanel Documentation Now my website is down with this "file not found" issue and I have no ideia how to turn back to cgi without php-fpm. Anyone can help? 0 -
Remove or empty the fpm.conf files for the problem domains /etc/apache2/conf.d/userdata/std/2_4///fpm.conf /etc/apache2/conf.d/userdata/ssl/2_4///fpm.conf Rebuild Apache /scripts/rebuildhttpdconf Restart Apache /scripts/restartsrv_httpd You may also want to post the contents of the fpm.conf file so we may be able to help fix. 0
Please sign in to leave a comment.
Comments
23 comments