FPM Executes But FCGId and CGI Just Download

19 posts / 0 new
Last post
#1 Wed, 08/23/2017 - 23:44
jabowery

FPM Executes But FCGId and CGI Just Download

VIRTUAL SERVER -> SERVER CONFIGURATION -> WEBSITE OPTIONS -> PHP script execution mode

Presents 3 options that run as virtual server owner but the only one that executes the PHP scripts is FPM. The others (FCGId and CGI) download the PHP source.

I need to get off of FPM. Is there a virtual server configuration checker that will tell me what I need to fix?

Thu, 08/24/2017 - 06:24
Joe
Joe's picture

This was a bug that was present for a few days in the installer.

You should be able to fix it by running:

# virtualmin config-system --include Apache

And then restart Apache:

# systemctl restart httpd

Also, why the aversion to FPM? It performs very similarly to fcgid (slightly better in some cases, slightly worse in others), has similar memory characteristics, and can share opcaches (so, probably more memory/performance efficient for servers with a few heavily loaded sites instead of many lightly loaded sites), provides similar security, and has a simpler configuration so it is less prone to problems (like this one). I'm testing moving to FPM for all of my sites rather than trying to get off of it.

So, is there a specific problem caused by PHP-FPM for you? Perhaps we can solve that, too.

As an aside, there are some newer, somewhat faster, options out there on our radar (PHP-PM and PHPFastCGI; naming in PHP world is not very original or distinctive, and it's stupidly confusing to talk about this topic), but both of those can lead to memory leaks, and maybe even security concerns, and require much more careful coding than I expect average PHP apps to exhibit, so they aren't in our immediate plans, and I think we need to be fully committed to removing mod_php completely before adding any new complexity to the PHP execution modes in Virtualmin.

--

Check out the forum guidelines!

Thu, 08/24/2017 - 09:38 (Reply to #2)
jabowery

I didn't run the new installer. The original run of a virtualmin installer on this system was 2011. The next time I renewed my virtualmin license and ran a virtualmin upgrade was this year -- and problems emerged, like this one, with which I have been wrestling ever since.

So, should I run:

virtualmin config-system --include Apache

Or will that just send me further into the weeds?

PS: I need to get off of FPM because I need to switch to a PHP version that supports curl on Debian 9 to which I had to upgrade so I could access the JSON parsing functions (that only exist on an upgraded version of mariadb depending on Debian 9), and whenever I go to switch the virtual host's php version in:

Virtualmin -> (select virtual host) -> Server Configuration -> PHP versions

I get the misleading message:

This virtual server is using the mod_php or FPM execution mode for PHP, such does not allow per-directory version selection.

Which, after a bunch of searching, I discovered should really read:

This virtual server is using the mod_php or FPM execution mode for PHP, such does not allow per-virtual server version selection.

I suppose I could try switching the entire system to PHP7 (which is the only one that has the php-curl packages for Debian9). But how do I do that?

Thu, 08/24/2017 - 12:01 (Reply to #3)
Joe
Joe's picture

Oh, no, you shouldn't run that command on an old system. It's currently only recommended for new systems, and probably won't solve your problem anyway (and might introduce new ones). This is something different, and we'll have to sort it out via normal troubleshooting.

The confusing bit is, you say you've got Debian 9? But, I thought "php" on Debian 9 is already PHP 7. Can you check what version(s) you've got installed there?

# dpkg-query -l php* |grep ii

--

Check out the forum guidelines!

Thu, 11/23/2017 - 21:46 (Reply to #4)
Matth
Matth's picture

Hello Joe,

I'm running into the same issue here on a Webmin GPL 1.860 / Virtualmin 6.01 / Debian 9 ( 1month old install) so i tried to run from the webmin command shell interface.

virtualmin config-system --include Apache

But then I got this message :

Command config-system.pl was not found

And running virtualmin --help effectively this option don't shows up

I'm i doing it wrong ? Or is there another way to fix this ?

Thanks

Matth

Thu, 11/30/2017 - 09:24 (Reply to #5)
rikus

How do you define the options for PHP-FPM pools? Is there some general settings you're using for all vhosts or they will be separately configured each? I mean stuff like pm.max_children, pm.start_servers etc.

As a default, Virtualmin uses these, obviously max_children is very wrong:

pm = dynamic
pm.max_children = 9999
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 5
Thu, 12/07/2017 - 06:58 (Reply to #6)
Matth
Matth's picture

Personaly I let Virtualmin doing this job for me, from what i understand there is a master config file here:

/etc/php/7.0/fpm/php-fpm.conf

And then I have a config file for each Vhost in path which look like that :

/etc/php/7.0/fpm/pool.d/151253956893246.conf

And finally the file for each Vhost look like this:

[151253956893246]
user = galery
group = galery
listen = 8002
pm = dynamic
pm.max_children = 9999
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 5
php_admin_value[upload_tmp_dir] = /home/galery/tmp
php_admin_value[session.save_path] = /home/galery/tmp
php_value[memory_limit] = 32M
php_value[session.save_path] = /home/galery/tmp

Hope that help.

Matth

Thu, 12/07/2017 - 08:08 (Reply to #7)
rikus

Hi Matth, yeah that's the default behaviour. But that max_children value is totally wrong, you should never have value that high there as a default, that could choke your server. If your average PHP process is, let's say ie. 50MB, then only one of your virtual hosts could use up to 500GB of memory, which you most likely don't have.

max_children could be counted like: "memory reserved for PHP / average PHP process size", but it's not that simple with multiple FPM pools, as I think they all should be counted in. All the pools are running same time anyway and you might have a high peak of visitors on multiple sites at the same moment.

Maybe change max_children to something like 15 as a default and then keep adjusting it for each vhost when needed. That's what I was wondering, what could be the reasonable value to have as a default, definitely not 9999 :)

Thu, 12/07/2017 - 19:26 (Reply to #8)
Matth
Matth's picture

Hello Rikus,

Super thanks for the tips, it's a very interesting one !

FYI, i tried to add this option in the server template but it doesn't change anything of the fpm pool config file.. (see pastebin image below)

http://picpaste.com/V9DjFKCa.PNG

Cheers Matth

Matth

Thu, 12/07/2017 - 19:50 (Reply to #9)
rikus

You can change the default value in Server Templates -> PHP options -> Additional FPM pool options:

pm.max_children = 15

Might be a good idea to have some fail-safe value for max_request too, which isn't there at all:

pm.max_requests = 200

If your site is busy, you should also change start_server, min_spare_servers and max_spare_servers. For very quiet sites might be a good options to change pm from dynamic to ondemand, so they won't reserve processes at all before site has visits.

Thu, 12/07/2017 - 21:01 (Reply to #10)
Matth
Matth's picture

Hum, this exactly where I add option but at the Vhost creation the pm.max_children option is still 9999 for the new vhost. Do you confirm I just have to respect the fpm config file syntax right ? Have you seen the screenshot I've add in the previous message ? Does it looks ok ?

Matth

Thu, 12/07/2017 - 21:11 (Reply to #11)
rikus

Yes, same syntax as in config files. That option should overwrite the default value, but ofcourse that only works for server created after the change. Works for me very well.

Thu, 08/24/2017 - 13:36
jabowery

I know I have php7* installed because when I run:

Virtualmin->System Settings -> Re-Check Configuration

I get:

The following PHP versions are available : 5.6.30 (/usr/bin/php5-cgi), 5.6.31 (/usr/bin/php5.6), 7.0.22 (/usr/bin/php-cgi7.0), 7.1.8 (/usr/bin/php7.1), 5.6 (mod_php)

But when I run your query:

root:~# cat /etc/debian_version
9.1
root:~# dpkg-query -l php* |grep ii
root:~# dpkg-query -l php*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
un  php5           <none>       <none>       (no description available)
Thu, 08/24/2017 - 14:45 (Reply to #13)
Joe
Joe's picture

What the heck? I have no idea what's happening there.

You said this system was upgraded from Debian 8? It seems like something went weird. That doesn't make sense.

--

Check out the forum guidelines!

Fri, 08/25/2017 - 13:06 (Reply to #14)
jabowery

Why doesn't:

Virtualmin->System Settings -> Re-Check Configuration

determine which PHP versions are available with the command:

dpkg-query -l php* |grep ii

?

Fri, 08/25/2017 - 16:59 (Reply to #15)
Joe
Joe's picture

Virtualmin is probably doing the more reasonable thing for figuring out what is actually available.

I just wanted to know what php packages you have installed, which is not what Virtualmin wants to know when it re-checks configuration.

I'm just confused, but I'm often confused by dpkg/apt.

--

Check out the forum guidelines!

Sat, 08/26/2017 - 12:50 (Reply to #16)
jabowery

OK, I've had it. I'm going to nuke my present linode instance and deploy a clean Debian 9 image upon which I'll install the latest Virtualmin and then reinstall my Wordpress virtual hosted sites from clones created with the Duplicator plugin. The only problem I have now is that one of my sites is returning "File not found." which is the enigmatic error produced by FPM under some circumstances -- an enigma that is not penetrated by LogLevel trace6 -- So I can't use the Duplicator plugin on that one.

Thu, 08/24/2017 - 20:53
burta.cart32

I had to run the command about 3 times and reboot, then it worked (ツ)

Thu, 12/07/2017 - 22:30
andreychek

Howdy,

I'd be curious what this command shows:

find /etc/apache2 -type f | xargs grep -i sethandler

Often, the downloading of PHP files is caused by a SetHandler line in the Apache config that shouldn't be there. The above command will show all of them, and then we can use that information to determine if one of them shouldn't be there.

-Eric