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.
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:
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?
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.
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
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
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.
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 ?
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.