Resolved Plesk not reloading service of custom PHP handler

[Jayfin3]

Server operating system version

Ubuntu 20.04.5 LTS

Plesk version and microupdate number

18.0.49 Update #2

I have a strange issue with a custom PHP-FPM handler I added. Mostly, it's working perfectly, except for the issue below:

When I switch a domain's PHP handler from my custom handler to another one, my custom handler's systemd service is not being reloaded. As a result, the service does not notice that the pool config has been removed from the poold and keeps using the .sock file in /var/www/vhosts/system/<domain>

That leads to the new handler's service complaining about the php-fpm.sock being in use:

ERROR: Another FPM instance seems to already listen on /var/www/vhosts/system/<domain>/php-fpm.sock

Now the interesting thing is: When switching a domain from a pre-existing handler (for exampe plesk-php81-fpm) to my custom handler, both handlers' services are reloaded. So plesk-php81-fpm notices the now removed pool config, releases the .sock file and so my handler's service can open it.


Can anyone give me a hint on what might be the issue here?

 

[Kaspar]

What PHP version are you running with the custom handler?

 

[Jayfin3]

8.1.14

 

[Kaspar]

I believe there are some rare issues with PHP 8.1.x which are still under investigation that can cause the php-fpm.sock error. I recommend contacting Plesk support for investigation on your server and a possible solution. You can mention issue PPS-13814 as your issue might be related.

 

[Jayfin3]

Thank you for your reply.

To me it seems to be unrelated to the PHP version, as there's no systemctl reload being issued by Plesk, which is being issued when using default handlers - even PHP 8.1. If I issue the reload command myself, while Plesk is still trying to restart the new handler's service, everything works fine.

But apart from defining the systemd service in plesk bin php_handler --add -service <service name> [...] there's nothing I have to do, right?

 

[Peter Debik]

Hi @Jayfin3, so your point is that "no systemctl reload is issued on a change of PHP handlers when changing from any custom handler to any other handler, regardless whether the other handler is also custom or built-in" while this is done when handlers are used that have been installed through Plesk. Would that be a correct description of the situation?

 

[Peter Debik]

I believe there are some rare issues with PHP 8.1.x which are still under investigation that can cause the php-fpm.sock error.

@Kaspar please see PHP-FPM seagfault after update from PHP 8.1.13 to PHP 8.1.14 · Issue #10461 · php/php-src, I think this entry results from your case. The issue is all over the Internet and is probably caused by a glitch in PHP itself that needs to be fixed by PHP developers. But as you can see, they have been informed and it seems they have also already reacted properly. As always, it'll take a while to trickle down again from PHP group to reach users' installations. I hope it won't take too long.

 

[Jayfin3]

Hi @Jayfin3, so your point is that "no systemctl reload is issued on a change of PHP handlers when changing from any custom handler to any other handler, regardless whether the other handler is also custom or built-in" while this is done when handlers are used that have been installed through Plesk. Would that be a correct description of the situation?

Absolutely correct.

The custom handler was installed using plesk bin php_handler --add, including the -service parameter. You can tell that Plesk knows about the correct service as it's restarted / reloaded correctly for example on changed setting or when switching a domain's handler to the custom handler instead of from it.

 

[Peter Debik]

I have submitted a report and forwarded it to developers for further analysis. You can monitor how this case proceeds here: Forwarded to devs - Custom PHP versions: no systemctl reload is issued on a change of PHP handlers when changing from any custom handler to any other handler

 

[Jayfin3]

Thank you very much. A small correction: "In such a case the pool config is not removed" is not correct. The file is removed, but the custom handler's service doesn't notice that because of the missing reload.

That's why all that is needed for everything to work is a manual reload after you clicked "Ok" in the Plesk UI. As Plesk waits for the unsuccessful restart of the target handler's service, and that service keeps trying for about 30 seconds, you have quite a bit of time to do it manually. After the reload the service releases the .sock file and the new service restarts happily.

 

[Peter Debik]

Thank you, I have updated the report(s) accordingly.

 

[Peter Debik]

@Jayfin3 Developers were not able to reproduce it. Please check Forwarded to devs - Custom PHP versions: no systemctl reload is issued on a change of PHP handlers when changing from any custom handler to any other handler
If possible, please describe how your custom PHP was installed.

 

[Jayfin3]

I answered in the thread you linked.

 

[Peter Debik]

Developers found that the existing libraries were reused for creation of a custom handler. This does not work. Instead, please install custom PHP versions seperately as described in the steps of the issue report. This is not a product issue, instead, reusing already configured libraries is a technically unsupported approach.

 

[Jayfin3]

Isn't that the exact same thing the FPM-dedicated created by Plesk handler does? Don't see any differences in the setup, except for the missing reload?

 

[Peter Debik]

The problem results from using the same PHP installation for a second handler.

 

[Jayfin3]

I understood, but so does the dedicated handler installed by plesk. Output of plesk bin php_handler --list, only the relevant lines:

plesk-php81-fpm              8.1.14         8.1.14       8.1      fpm  /opt/plesk/php/8.1/sbin/php-fpm  /opt/plesk/php/8.1/bin/php  /opt/plesk/php/8.1/etc/php.ini     true  enabled
plesk-php81-fpm-dedicated              8.1.14         8.1.14       8.1      fpm  /opt/plesk/php/8.1/sbin/php-fpm  /opt/plesk/php/8.1/bin/php  /opt/plesk/php/8.1/etc/php.ini     true  enabled