• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Forwarded to devs php-fpm service unavailable after domain removed from Plesk

burnley

Regular Pleskian
TITLE:
php-fpm service unavailable after domain removed from Plesk
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Plesk Onyx
Version 17.5.3 Update #47, last updated on May 9, 2018 10:27 PM on CentOS 7.4
PROBLEM DESCRIPTION:
I see there's already a KB article on this issue:
Unable to switch php handler: plesk-phpXX-fpm, action "status" failed

It happened on one of our servers yesterday night, after a domain got deleted from Plesk php-fpm wasn't able to reload because the domain configuration file was still present in the php-fpm.d directory of that handler.
We need to know whether there's any ticket opened already for this bug and when we can expect a fix.​
STEPS TO REPRODUCE:
Delete domain configured to use php-fpm in Plesk. Can't reliably reproduce it.​
ACTUAL RESULT:
After the domain is removed the php-fpm service goes spinning on reload with:

ERROR: [pool subdomain.example.com] the prefix '/var/www/vhosts/system/subdomain.example.com' does not exist or is not a directory​
EXPECTED RESULT:
When the domain is deleted from Plesk it's config is also removed from php-fpm.d directory, *then* php-fpm service is reloaded.​
ANY ADDITIONAL INFORMATION:
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
From developer:

Unfortunately, I cannot investigate this because it relies on Panel's reliability. It could not be investigated without the debug information in panel.log and other multiple knowledge about the mentioned server.

So, I recommend you contact Plesk Support Team for deep investigation directly on your server.
 
Thanks Igor. As I've already mentioned it's random, in fact we've only seen it once and enabling debugging in Plesk is a no-no for production. I'll try to collect more information from the affected server and contact support.
 
Any chance the developers can make the fpm process more fault tolerant in event of missing config file vs kill all the sites using that fpm hander. i.e skip or exclude missing files?
 
Is it possible that, under *some* circumstances, Plesk creates php-fpm configuration for 2 different handlers and, when deleting the subdomain, it only deletes one of them? These are the action log entries which might have been a factor in the bungle. Coming from 127.0.0.1 I assume they're Plesk API calls:
127.0.0.1 admin [2018-05-23 18:39:03] 'Create Physical Hosting' ('Client GUID': '5c62707c-5410-497c-b93b-e86a062f1831' => '5c62707c-5410-497c-b93b-e86a062f1831', 'Domain GUID': '8dab6f79-c658-43fc-be27-04210c693f7f' => '8dab6f79-c658-43fc-be27-04210c693f7f', 'Domain Name': 'wp.domain.com.au' => 'wp.domain.com.au', 'IP Address': '' => '192.168.1.216', 'Mod FastCGI Support': 'false' => 'true', 'PHP Handler': 'fpm' => 'remi-php70-fpm', 'PHP Support': 'false' => 'true', 'SSI Support': 'false' => 'true', 'SSL Support': 'false' => 'true', 'WWW Root': '/var/www/vhosts/domain.com.au/httpdocs' => '/var/www/vhosts/domain.com.au/WP.domain.com.au')
127.0.0.1 admin [2018-05-23 18:39:04] 'Update Physical Hosting' ('Client GUID': '5c62707c-5410-497c-b93b-e86a062f1831' => '5c62707c-5410-497c-b93b-e86a062f1831', 'Domain GUID': '8dab6f79-c658-43fc-be27-04210c693f7f' => '8dab6f79-c658-43fc-be27-04210c693f7f', 'Domain Name': 'wp.domain.com.au' => 'wp.domain.com.au', 'IP Address': '' => '192.168.1.216', 'Mod FastCGI Support': 'false' => 'true', 'PHP Handler': 'fpm' => 'remi-php72-fpm', 'PHP Support': 'false' => 'true', 'SSI Support': 'false' => 'true', 'WWW Root': '/var/www/vhosts/domain.com.au/httpdocs' => '/var/www/vhosts/domain.com.au/WP.domain.com.au')
Note the 2 actions, create & update, 1 second apart.
 
Ok, it's easy to reproduce the bug when restoring from the Plesk backups. Here are the steps:

1. Prerequisites:
- Plesk Version 17.5.3 Update #47 on CentOS 7
- Multiple php-fpm handlers installed and already configured for other existing vhosts
2. Create a test subscription, I used adit3.local. Configure it to use php-fpm 7.0 as Apache handler
3. Create a subdomain, I used wp2.adit3.local and configure it to use php-fpm 7.2 as Apache handler. Install Wordpress on wp2 subdomain (haven't tried without installing WP, though).
Verify everything is properly configured and running after steps 2 and 3.
4. Do a full backup of the entire subscription and verify it finished successfully.
5. Delete wp2.adit3.local subdomain from Plesk. Leave adit3.local domain untouched.
6. Do a full restore from the backup previously created, wait for task completion
BUG! After the task finished and the subdomain with all its configuration and data were restored I've ended up with the following:
- In the panel php version was showing 7.2 as FPM using Apache, however:
- The php-fpm handler configured by Plesk was actually 7.0, according to the file present in /etc/opt/remi/php70/php-fpm.d/wp2.adit3.local.conf. No /etc/opt/remi/php72/php-fpm.d/wp2.adit3.local.conf
7. Now delete wp2.adit3.local.conf subdomain from the panel. Plesk thinks the subdomain is running 7.2, therefore doesn't remove the live configuration from /etc/opt/remi/php70/php-fpm.d/wp2.adit3.local.conf. Leaving the conf file in place breaks php70-php-fpm handler:
/opt/remi/php70/root/usr/sbin/php-fpm -t
[28-May-2018 15:55:34] ERROR: [pool wp2.adit3.local] the prefix '/var/www/vhosts/system/wp2.adit3.local' does not exist or is not a directory
[28-May-2018 15:55:34] ERROR: failed to post process the configuration
[28-May-2018 15:55:34] ERROR: FPM initialization failed
Reloading php70-php-fpm handler now breaks all the other sites using it:
[...]
[28-May-2018 16:16:26] ERROR: [pool wp2.adit3.local] the prefix '/var/www/vhosts/system/wp2.adit3.local' does not exist or is not a directory
[28-May-2018 16:16:26] ERROR: failed to post process the configuration
[28-May-2018 16:16:26] ERROR: FPM initialization failed
[28-May-2018 16:16:30] ERROR: [pool wp2.adit3.local] the prefix '/var/www/vhosts/system/wp2.adit3.local' does not exist or is not a directory
[28-May-2018 16:16:30] ERROR: failed to post process the configuration
[28-May-2018 16:16:30] ERROR: FPM initialization failed
[...]
Removing /etc/opt/remi/php70/php-fpm.d/wp2.adit3.local.conf manually fixes the 7.0 handler
 
Thank you. Request PPPM-8651 was submitted.
Exactly how you describe it was not possible to reproduce, but there were problems with custom PHP from remi. For Plesk 17.5, the config after restoration is not restored at all (you say that the config is moved to another PHP), and for 17.8 the config is just not created already at the stage of creating the subdomain.
 
Back
Top