Php-fpm setting needs validated against pm.min_spare_servers and pm.max_spare_servers

VirtualMin 7.1 gpl
RedHat 7

trying to be frugal, on my new test 7.1 system I adjusted the PHP FCGId sub-processes item on the PHP Options panel to be 4. Then I was in for a surprise – the php-fpm process died – that is, during the shutdown/restart action, it did shut down but then failed to start back up !!

It says in the logfile /var/log/php-fpm/error.log

ALERT: [pool 155655479617843] pm.min_spare_servers(1) and pm.max_spare_servers(5) cannot be greater than pm.max_children(4)

I see in, in the routine create_php_fpm_pool that some values are hardcoded:

                   "pm.start_servers = 1",
                   "pm.min_spare_servers = 1",
                   "pm.max_spare_servers = 5",

I am not sure of the correct place to put a sanity check, but I respectfully suggest one is needed … to avoid the issue I ran into today.

At times at the SSH command line when I am tweaking things by hand, I will run

php-fpm -t

before doing a reload/restart, but I don’t know if that can be generalized or automated.


@verne - go find your php pool conf files - perhaps in


replace 7.4 with whatever version you are using and you need to either set pm.max_spare_servers = 4, or set pm.max_children = 5.

Virtualmin may set some other original values - when I create a Virtual Server, I always go to it’s pool conf file and set them to what I want\need.



Thanks, good point !! But I worry that its a bad design when a minor change via the GUI can cripple my system.


@verne - there may well be somewhere in the GUI that you can set whatever “baseline” values you want, but I just set them manually in the files and the GUI doesn’t overwrite them - so the chance of the GUI crippling your system is NIL.


I see patch bf66dca to on github back on July 29 addresses this issue !!!


Yes, you are right – it was a bug and I think I have already fixed that. Where exactly did you make the change? If that was PHP Options page, it will be fixed in Virtualmin 7.2 release.

Yes, most probably that’s the one.

I installed virtualmin 7.2.gpl-1 on Ubuntu22.04(aws ver) yesterday, but I came to see the same problem.

I made a first domain to use php8.1-fpm, and php8.1service stops.

In /etc/php/8.1/fpm/pool.d/www.conf, it is set as below.

pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

But in /etc/php/8.1/fpm/pool.d/16651099103631.conf, made by virtualmin when create first domain , it is set below

pm.max_children = 3
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 5

So stop with the error below.

pm.min_spare_servers(1) and pm.max_spare_servers(5) cannot be greater than pm.max_children(3)

Is there some more setting need to use the fpm?

Bring up VirtualMin on port 10000 in a browser. Log in. Choose your domain in the VirtualMin pulldown menu.

Expand the Server Configuration item. Then choose PHP Options.

On that panel, when FPM is chosen (if you have a choice), there is the item

PHP FCGId sub-processes

adjust that to be 5 or more (or whatever you see for pm.max_spare_servers) – this value is used for pm.max_children for this domain. Then start php-fpm for 8.1 back up again. You will have to do this by hand for each new domain.

I have no idea how to fix the root cause (well, if you are very brave, you can edit the VirtualMin PL scripts/files :slight_smile: – that is, how to make VirtualMin handle this issue). But you can adjust your Server Template for all future domains … in VirtualMin, expand the lower menu section System Settings. Then choose Server Templates.

Once there, choose Default Settings, or make a new custom one for yourself. Once you are viewing a Server Template, use the pulldown to choose PHP Options. Once on that panel, adjust

Default FCGId PHP sub-processes

to be 5 or more (or whatever you see for pm.max_spare_servers) – this value is used for pm.max_children for all new domains.

Next, upcoming Virtualmin 7.2.1 (or 7.3) will have pm.max_spare_servers dynamically set.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.