• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

How to keep php-fpm from breaking?

HostaHost

Silver Pleskian
On Plesk 12.5, we're starting to experiment with using PHP-FPM instead of FastCGI for our customers. However, we are frequently running into an issue where php is broken across every site on the server due to the PHP-FPM daemon not starting. This has been tracked back to Plesk allowing subdomains to be deleted without cleaning up the config file in /etc/php-fpm.d/. That causes the FPM daemon to fail with:

[24-May-2016 12:32:22] ERROR: [pool test.domain.com] the prefix '/var/www/vhosts/system/test.domain.com' does not exist or is not a directory
[24-May-2016 12:32:22] ERROR: failed to post process the configuration
[24-May-2016 12:32:22] ERROR: FPM initialization failed

At that point, php is broken on every site on the server.

This issue is documented in KB https://kb.plesk.com/en/127183 where Plesk's solution is just oh, your php is broken, well go remove the file that's breaking it.

The Self Repair tool does NOT fix the issue; i.e., if there is a now-bogus file in /etc/php-fpm.d/ referencing a site that does not exist, and you tell Plesk to do a self repair of all web server config, it will not go remove the file, so php-fpm remains broken.

Having watchdog monitor it doesn't matter because it can't be restarted at this point anyway.

The value that seems to cause the problem is this:

php_value[open_basedir] = "/var/www/vhosts/test.domain.com/:/tmp/"

since the failure is based on a directory, and that appears to be the only site-specific directory Plesk puts in the config file for each php-fpm enabled domain.

Other than setting every site to have an open_basedir of none, has anyone found a workaround for this? Any chance the php-fpm config files support conditionals so you could test for the directory's existence before the config directive is parsed?
 
Thank you for this report. I have escalated this issue to Support Team. They will contact you in scope of created ticket.
 
well, we also just (after plesk update to #33) had 55.9 by vendor php-fpm broken and got the sites up only after downgrading to 5.3. fast-cgi.
why do we always have to fear plesk updates? (they also had killed my magic spam repeatedly)
do you huys really know what you are doing?
edgar
 
Back
Top