• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Plesk 12.5 PHP-FPM - pool config not removed when PHP support turned off

TimReeves

Regular Pleskian
Configure a domain with PHP-FPM support (in my case via Nginx). The pool config is created as expected. Then in Plesk turn off PHP support for the domain.

The pool config remains present (with timestamp of the switching off, i.e. it was recreated, although it should not have been).
 
@TimReeves

Can you be more specific? Which PHP version? Does it happen on a specific domain? And so on.

Note that I suspect that you should have a look at the state of the php-fpm.sock file in the directory /var/www/vhosts/system/<domain>.

If you disable the php-fpm support for a specific domain in the Plesk Panel, just remove php-fpm.sock in before mentioned directory and re-enable php-fpm support again.

That should do the trick, if it does not, please report some additional details, to allow us to help.

Regards....
 
@trialotto Thanks for your reply. There's not a lot I can add. It's not a about one particular domain, this keeps happening to me, on at least 2 Plesk servers (Ubuntu 14.04 LTS). It seems to be the border case of changing from 0 to 1 or 1 to 0 members in a particular FPM pool. Plesk not noticing to actually stop or start the service?

But I did just notice something else disturbing: My Plesk had long updated PHP to 7.0.1 - but 7.0.0 was still being served! Really, I saw it on phpinfo(). I was looking at phpinfo() because Plesk had just again failed to restart the master process for the pool of PHP 7.0, after I had reassigned a new domain to it (away from default OS-Vendor PHP). The FPM log was noting that a socket appeared to be already set by another FPM instance. Well, that was the still-running 7.0.0. A manual restart "service plesk-php70-fpm restart" did the trick, now I'm seeing 7.0.1 and there was no problem to restart the FPM instance. Maybe Plesk needs to be using more "restart" than "start"? That way, it does'nt matter if an instance is already running or not, making things more robust.

Sorry to have to be "whinging", but my situation with the FPM pools and Plesk remains sadly unstable )-:
 
@TimReeves

Well, it is not "whinging" at all, to the contrary: your specific situation often is the culmination of multiple (minor) previous errors.

Normally, one would consider the most elaborate solutions, including command line actions and all kinds of analysis, but that should not really be necessary: Plesk is more than decent, in the sense that it is able to correct some of your issues by just switching php versions and/or fpm modules.

Try the following (after having checked first that you are on micro-update 17 or 18):

a) with respect to the fpm issue:

1 - go to the troublesome domain in question and go to "PHP Settings": change "FPM served by ..." to "Fastcgi application served by Apache", (and)
2 - if that works, revert the settings by undoing your changes: select "FPM served by Apache" again and it should work fine.

If you encounter any problems (error notifications in red), just retry step 1 and verify in a SSH console that /var/www/vhosts/system/<domain> does not contain a php-fpm.sock file (and if it does, just delete it and execute before mentioned step 2).

Note that you really have to press "OK" (and not "Apply") when executing steps 1 and 2.

Also note that the above "solution" is not dependent on the version of php, it should work for all php versions.

Having said (or repeated) the above, we can continue to your actual statement.

b) with respect to the php issue: you stated

But I did just notice something else disturbing: My Plesk had long updated PHP to 7.0.1 - but 7.0.0 was still being served! Really, I saw it on phpinfo(). I was looking at phpinfo() because Plesk had just again failed to restart the master process for the pool of PHP 7.0, after I had reassigned a new domain to it (away from default OS-Vendor PHP). The FPM log was noting that a socket appeared to be already set by another FPM instance. Well, that was the still-running 7.0.0. A manual restart "service plesk-php70-fpm restart" did the trick, now I'm seeing 7.0.1 and there was no problem to restart the FPM instance. Maybe Plesk needs to be using more "restart" than "start"? That way, it does'nt matter if an instance is already running or not, making things more robust.

The restart command is nothing more (or less) than a sequence of stop and start (i.e. it is not a graceful restart).

In essence, an educated guess would be that your previous version of php has been claiming a php socket at installation time of the new php version: a failure to stop properly would result in a failure to start the new php version at post-installation time, whereas before mentioned failure to stop (the old php version) would be caused by (previous) stop/start failures of the old php version, with the latter stop/start failures often being the result of manual actions (and not being the result of Plesk running improperly).

After all, it has always been possible to "activate" or, if necessary, "enforce" the start of fpm via the Plesk panel, irregardless of the php version (see section a)).

Sure, I must admit that some of the earliest versions of Plesk 12.5.30 did cause some minor problems, but these were patched, implying that a failure caused by Plesk is not very likely to be the underlying root cause of a number of consecutive (minor) problems.

For that reason alone, I must emphasize that section a) contains an approach that will end the sequential occurrence of php/fpm related issues.

In short, it is not an issue of starting or restarting, as you stated, but more or less a matter of manual actions.

To be honest, I also forget to undo some settings, when I try to reproduce an error: this can lead to "false negatives", i.e. issues that are not issues at all, but human mistakes.

In conclusion, it is my humble advice to start from scratch and/or systemically think about all possible explanations, whenever tackling any issue.

Regards....
 
Thanks for the detailed explanation - but I'm still having frequent problems with FPM pool configs. The latest example: I turned off PHP support for a domain which had it previously via Plesk PHP 7.0.1 via Nginx/FPM. Plesk then shows the domain as without PHP support, and "ps" shows that FPM was restarted at that time. BUT the pool config for the domain (and thus also its socket) were still present. I have to remove it by hand. This is Plesk 12.5.30 Update #18, last updated at Jan 4, 2016 07:13 PM (as provided by HostEurope). BTW I use a comprehensive own Nginx config and switch off "Smart static files processing" in Plesk - could that cause Plesk to trip up?
 
@TimReeves

You are correct, when disabling PHP support, the php-fpm.sock and the <domain>.conf file remain present, but that should not really be a problem.

It is not really necessary to remove them by hand, by disabling PHP support you will end up with a site that does not render php files (i.e. pages or similar).

In short, the system will not become unstable.

However, note that you have to safeguard your site when disabling PHP site on your site: html is presented normally (no worries here), but php files are offered as a download (i.e. any person can have a peak and view at your code, which is not desirable at all).

Finally, you stated
I use a comprehensive own Nginx config and switch off "Smart static files processing" in Plesk - could that cause Plesk to trip up?

Ehm, to be honest, I would have to say "No" to your question, but there are two relevant remarks: (on the one hand) bad configuration of Nginx can cause some (minor) problems and errors can be made relatively quick and (on the other hand) the default Nginx template in Plesk is somewhat peculiar, in the sense that one has to delete specific file extensions in the checkbox below "smart static file processing by Nginx", if (and only if) one specifies custom directives for the file extensions in question (otherwise, the custom directive fails to work).

Regards.....
 
@trialotto Thanks for your corroboration of my observation that FPM pool configs remain present when PHP support is disabled.

Also, if I remove them manually then calling "/usr/local/psa/bin/php_settings -u" reinstates them!

I believe that you are correct - that the normal user does not see a problem. However, if I still have an own Nginx config in place which passes php requests to the socket, then PHP will be served.

Also, resources may be wasted on my server, I have noted two cases:
  • The pool config for a domain "without PHP support" is the only one for a particular PHP version (in my case the OS vendor version, as I otherwise use Plesk PHP7). Then a master process for that pool is started, which I just don't need.
  • I had previously manually added a php.ini to /var/www/vhosts/system/{domain}/conf, then turned off PHP support. Now, if the php.ini specified pm = dynamic, then those child process will be started, which, again, I just don't need.
Honestly, this sort of behaviour gets my back up. If I tell a programm to do something, I expect it to be done, not half-done. It gives me the feeling it's doing what it thinks may be best for me, not what I told it to do.

Furthermore I have often had problems lately in this area with Plesk, as noted above. Basically because of this effect, I reckon - a pool-config (plus socket) which IMHO should not be there, block a new configuration (e.g. other version of PHP) - and the solution suggested is that I should first select another web-service model and then revert...

Quite honestly, I reckon that Plesk is shooting itself in the leg here :(

@trialotto Please don't take this personal, I really do appreciate the long replies you wrote me. It's not about us, but about Plesk!

Regards, Tim
 
Even for domains which NEVER had PHP support (created in a subscription with a service plan without PHP support), good ol' Plesk generates PHP config, i.e. for EVERY domain on the server, it would seem. That is because in its hosting table it ALWAYS puts a valid entry as the 'php_handler_id'. So, some sort of PHP config will always get generated. Damn.

Code:
# /usr/local/psa/bin/php_settings -u

The only workaround (assuming no custom templates) is to manually edit Plesk's "psa" database, inserting an unknown PHP handler name, so that Plesk does not know what to do:
  • Open the "psa" database on the server in phpMyAdmin (Tools + Settings | Database Servers | Tools-Icon at right end of MySQL line)
  • Open the table "domains" and note the 'id' (1st column) of the domain(s) in question ('name' is 3rd column)
    Alternatively you can recognise the domain in the 'www_root' column of the "hosting" table.
  • Open the table "hosting", go to the line defining the hosting of the domain(s) in question, and edit the column value 'php_handler_id' to the empty string.
Now, the settings update CLI job will complain: Domain "blah.com": the PHP handler "" is not registered.
But that's just a warning message - no pool config is created as the script does not know which pool.

Well, it's a bit ugly, but it works. Note that there MAY be knock-on effects (e.g. when deleting the subscription).

An alternative - if like me you have custom templates to eradicate Apache config - would be to select:
run PHP as "FastCGI application served by Apache" - no FPM pool because FastCGI, no FastCGI because Apache-Config eradicated.

P.S. When a subscription is deleted, Plesk may well leave all the files and some DB entries lying around )-:
 
Back
Top