Issue Issues with FPM

[Tozz]

We are using the latest version of Plesk Onyx (with all patches and updates installed) on both Debian 8 and Debian 9 machines. The way Plesk handles mutations to FPM is giving us headaches and negative customer feedback.

It all seems to boil down to the fact that Plesk sometimes mishandles changes to FPM. There are multiple issues:

- When changing PHP version, sometimes the pool config is not removed from the old PHP version. This leads to a conflict where one of the FPM's can't restart due to an already existing socket for that specific website. Funny thing is, this doesn't always happen (its not easily reproduced).

Log says:
Nov 5 09:08:48 rosalind php-fpm7.0[19367]: [05-Nov-2018 09:08:48] ERROR: An another FPM instance seems to already listen on /var/www/vhosts/system/X.be/php-fpm.sock
Nov 5 09:08:48 rosalind php-fpm7.0[19367]: [05-Nov-2018 09:08:48] ERROR: FPM initialization failed

However, when we verify now, there is only 1 pool config for this site:

# grep -r X /etc/php /opt/plesk/php
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.conf:; Panel or override settings in /var/www/vhosts/system/X.be/conf/php.ini.
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.conf:; section of /var/www/vhosts/system/X.be/conf/php.ini file.
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.conf:[X.be]
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.confhp_value[open_basedir] = "/var/www/vhosts/X.be/:/tmp/"

Could this be a race condition where Plesk tries to restart the new FPM's before it has restarted the old one to clean up the socket?

- When making a change to a serviceplan and sync the changes to all subscriptions using that plan, FPM often can't restart. Presumably this is due to the same reason (possible race condition)

I was wondering if anyone is seeing the same behaviour as we do. We frequently find FPM processes not running due to conflicting pools. Even subscriptions that we have manually removed the pool config (such as this X.be subscription) is causing us headaches again.

 

[Tozz]

A little update / additional information:

We have seen issues with "X.be" before, so I made the choice to migrate X.be to another server (by hand, not using migration manager). I then removed X.be from the old / source server. So the user is removed:

Plesk GUI:

Information: The account is removed.

Syslog says:

syslog:Nov  8 15:14:40 rosalind named[17135]: zone X.be/IN: (master) removed

- Account is removed from /etc/passwd
- /var/www/vhosts/X.be is gone
- /var/www/vhosts/system/X.be is gone

Yet:

# grep -r X /etc/php /opt/plesk/php
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.conf:; Panel or override settings in /var/www/vhosts/system/X.be/conf/php.ini.
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.conf:; section of /var/www/vhosts/system/X.be/conf/php.ini file.
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.conf:[X.be]
/opt/plesk/php/7.0/etc/php-fpm.d/X.be.confhp_value[open_basedir] = "/var/www/vhosts/X.be/:/tmp/"

Why isn't the FPM config removed?

This IS a Plesk generated config file, as the headers indicate:

; ATTENTION!
;
; DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
; SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.

Why isn't this config removed?

This is now an account removal, so the lack of pool removal isn't a very big issue. However, the same issues occures when changing FPM handlers for this site. So then there are 2 pools (2 PHP versions) for 1 subscription using _the same_ socket. This conflicts, resulting in 1 FPM daemon to fail to start

 

[Tozz]

My issue seems to be a known bug already?

Webserver Configuration Troubleshooter detects extra configuration

states: "In some cases, extra webserver configuration files remaining after removing domains might cause conflicts with webserver configuration rebuild process."

I would like to know what those cases are, so I can work around them

 

[Bitpalast]

I've seen this frequently, but have never seen a pattern. It seems to be a timing issue (race condition) that is causing this when an account is removed. The issue does not only occur with PHP-FPM configuration files. It occurs with SSL certificate files, webmail subdomain configuration files, other subdomain files, mail accounts (rarely, but I've seen it there, too), system user entries. Basically, it seems to occur with all stuff hat is involved with an account.

What we did here is to create scripts that check the configuration files each minute and auto-correct (auto-delete) them, if there are additional files that could break webserver restarts.