PHP pages no nolger load after 12.5.30 MU#23 update

[BSMenny]

After upgrading my Plesk VPS to 12.5.30 MU23. the PHP pages are no longer served by the PHP handler with the result of the browser asking which applications to use for opening the .php pages (see picture 1)



The current PHP engine is version 5.6.18 run as FPM Application served by Apache.

If I switch the PHP handler to either FastCGI Application served by Apache or FPM Application served by NGINX the php pages are handled correctly and are displayed by the browser.

How can I have my PHP content served correctly by the FPM-Apache handler after the MU23 upgrade?

Thank you

Luca

 

[IgorG]

Make sure that corresponding Apache module is enabled in Tools&Settings -> Apache Web Server

 

[BSMenny]

Igor,

Thank you for the reply.
I checked the Apache page on the control panel and the corresponding modules (php5, proxy , proxy_fcgi) are enabled. Any more suggestions?

 

[OGR]

Same problem here. This is on Ubuntu 14.04 and the pages were working fine. Then after I added a domain alias I guess the services were triggered with a reload and suddenly I get those downloads for all PHP pages (the source code is served). I can only guess that it was the MU23 that was installed two days before. Switching to FastCGI Application served by Apache or FPM Application served by NGINX or just using the Apache module provided by the OS and it works but FPM Application served by Apache is broken. The problem exists with PHP 5.6 and 7.0 by Plesk as well as the PHP 5.5.9 FPM provided by the OS.

The log files for the Plesk FPM installations say

[24-Feb-2016 21:38:10] ERROR: No pool defined. at least one pool section must be specified in config file
[24-Feb-2016 21:38:10] ERROR: failed to post process the configuration
[24-Feb-2016 21:38:10] ERROR: FPM initialization failed
[24-Feb-2016 21:38:11] ERROR: No pool defined. at least one pool section must be specified in config file
[24-Feb-2016 21:38:11] ERROR: failed to post process the configuration
[24-Feb-2016 21:38:11] ERROR: FPM initialization failed

I did not change anything in the configuration.

 

[OGR]

Update: After looking at MU23, I think that the contents of "php_over_fpm.php" are responsible for this. On another server I am lucky that MU22 is the last one that was installed. I switched that server to not autmoatically install updates in the Plesk update settings in the hope that Plesk will not automatically break several domains in the next days. Please fix this!

 

[trialotto]

@OGR

It has nothing to do with the update, it is all about the php-fpm handler.

Everything should be working fine out-of-the-box, but if it does not, just run the following commands (from the command line):

1) service plesk-php<xx>-fpm stop

2) service plesk-php<xx>-fpm start

and note that

- <xx> indicates the number for the php version: plesk-php70-fpm, plesk-php56-fpm and so on,
- the above two steps are sufficient to get everything running like a charm,
- you sometimes have to change the php version on the domain, in order to "refresh" php-fpm handlers, by reverting back to the previous PHP version (i.e. the PHP version desired).

Hope the above helps, it certainly is a quick solution to get everything working again.

Regards....

 

[IgorG]

Same problem here. This is on Ubuntu 14.04 and the pages were working fine. Then after I added a domain alias I guess the services were triggered with a reload and suddenly I get those downloads for all PHP pages (the source code is served). I can only guess that it was the MU23 that was installed two days before. Switching to FastCGI Application served by Apache or FPM Application served by NGINX or just using the Apache module provided by the OS and it works but FPM Application served by Apache is broken. The problem exists with PHP 5.6 and 7.0 by Plesk as well as the PHP 5.5.9 FPM provided by the OS.

The log files for the Plesk FPM installations say

[24-Feb-2016 21:38:10] ERROR: No pool defined. at least one pool section must be specified in config file
[24-Feb-2016 21:38:10] ERROR: failed to post process the configuration
[24-Feb-2016 21:38:10] ERROR: FPM initialization failed
[24-Feb-2016 21:38:11] ERROR: No pool defined. at least one pool section must be specified in config file
[24-Feb-2016 21:38:11] ERROR: failed to post process the configuration
[24-Feb-2016 21:38:11] ERROR: FPM initialization failed

I did not change anything in the configuration.

Here is explanation of this error messages - https://kb.odin.com/en/127195

 

[trialotto]

@IgorG,

Note that the KB article does not apply to the Apache vendor package, i.e. PHP version 5.5.9.

Regards

 

[OGR]

The remarks about the error messages only showing up in the log if no domain is configured to use the corresponding FPM handler are correct. Once you assign a domain to the handler, then the corresponding log file log looks okay:

[25-Feb-2016 06:40:58] NOTICE: fpm is running, pid 10732
[25-Feb-2016 06:40:58] NOTICE: ready to handle connections

This just makes the Plesk FPM handlers behave just like the OS vendor FPM service. Exactly like the OS service: It seems to run but delivers the PHP source code instead of parsing and executing it, just like BSMenny describes it. So this clears up the case of the log messages but the problem stays the same.

I did nothing on this server in the way of configuring any of the FPM services, this is all Ubuntu 14.04 distribution defaults and the Plesk packages. The PHP 7 from Plesk was running via FPM just fine and minutes after I added a domain alias in Plesk this error happened. The domain creation obviously triggers a service reload, so some error already waiting came to light just then. This must have happened through some automatic Plesk update, preferably MU23, since I did not find any obvious changes to the FPM config in earlier microupdates.

 

[OGR]

Now I could extract the previous configuration style from another server and revert the configuration on the server that has MU23 installed. And guess what: That fixes it!

+       <IfModule mod_proxy_fcgi.c>
+               ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:///var/www/vhosts/system/sub.domain.tld/php-fpm.sock|fcgi://127.0.0.1:9000/var/www/vhosts/domain.tld/sub.domain.tld
+       </IfModule>

        <Directory /var/www/vhosts/domain.tld/sub.domain.tld>
                # ...
#               <IfModule mod_proxy_fcgi.c>
#                       <Files ~ (\.php$)>
#                               SetHandler proxy:unix:///var/www/vhosts/system/sub.domain.tld/php-fpm.sock|fcgi://127.0.0.1:9000
#                       </Files>
#               </IfModule>

The lines marked with the "+" at the beginning were missing from the config file and instead the lines from the "php_over_fpm.php" were inserted inside the "Directory" directive. Commenting out those lines and reinserting the "+" lines fixes the problem. Of course all paths need to be adjusted and this change needs to happen at two places in the "plesk.conf.d/vhosts/sub.domain.tld.conf" file. And editing every such file is not a viable option, it should work out of the box.

To be clear, in this example the specific hostname is a subdomain but the problem also exists for regular domains. This subdomain only exists for such tests like this.

So, it is now clear that the microupdate broke PHP-FPM on Ubuntu 14.04. Please fix it!

 

[IgorG]

Guys, it would be more efficient if you submit support ticket about this problem with FPM Application served by Apache here - https://cscontact.plesk.com/form/32/?Product=Plesk
Our developers will check this issue in the scope of the support ticket.
Thanks.

 

[custer]

Guys,

Try launching Plesk Installer and installing the latest version of mod_proxy. Let us know if this doesn't work.

 

[trialotto]

@OGR

You stated

So, it is now clear that the microupdate broke PHP-FPM on Ubuntu 14.04.

This is not the case.

Note that your statement

The lines marked with the "+" at the beginning were missing from the config file and instead the lines from the "php_over_fpm.php" were inserted inside the "Directory" directive. Commenting out those lines and reinserting the "+" lines fixes the problem.

actually speaks of "reinserting" a line equal to

ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:///var/www/vhosts/system/sub.domain.tld/php-fpm.sock|fcgi://127.0.0.1:9000/var/www/vhosts/domain.tld/sub.domain.tld

with this line probably being the line associated with your comment "extract the previous configuration style from another server", i.e. this line is presumably previous configuration.

Also note that the default line (in php_over_fpm.php), as associated with micro-update 23 (MU23), is equal to

SetHandler proxy:<?php echo $VAR->domain->physicalHosting->fpmSocket ?>|fcgi://127.0.0.1:9000

and this is a templated line, meaning that you do not have to make changes to every "plesk.conf.d/vhosts/sub.domain.tld.conf" file.

I can only say, when comparing your line with default line (in php_over_fpm.php), that

1) your manual fix contains a mistake: let´s hope that you made a typo error by adding /var/www/vhosts/domain.tld/sub.domain.tld to the end of the line, but even though it should not be there, the type does not really matter, as I will explain later.

2) your manual fix contains the ProxyPassMatch instead of SetHandler: this is not NOT a good solution, as I will explain below.


PHP-FPM is a FastCGI process manager and, irregardless of the question whether you use ProxyPassMatch of SetHandler, these Apache directives both entail that some request is passed to the FastCGI server that is managed by PHP-FPM.

The ProxyPassMatch and SetHandler directive are different in the way they pass requests to the "backbone", in the sense that

a) ProxyPassMatch passes matching request URIs as a filesystem path to be run by the PHP-FPM daemon, implying that

- non-matching request URIs are not passed to PHP-FPM at all: this is not desirable, one should be careful with this
- your line contains a socket: PHP-FPM daemon is listening on (and using) the socket
- whenever a socket is being used: the fcgi:// part of your line will be ignored (this explains my remark at point 1)

and, given the above, the conclusion can already be that your line is not different from the default line, in the sense that they are both using the PHP-FPM daemon via the socket.

For the sake of convenience, I will first discuss the SetHandler directive briefly, before continuing and finalizing the conclusion.

b) SetHandler passes requests to be handled as reverse-proxy requests, by means of a handler. In this case, it is the plesk-php<xx>-fpm handler. The URI to filename mapping now occurs in the server and the local filesystem path is passed to fcgi:// backend. This method is associated with better performance and more accuracy.


It must be clear by now that both directives are using a socket to pass requests, implying that your line is working due to the facts that

- a socket is present
- a PHP-FPM daemon is running (otherwise, there would or should not be a socket)

and these facts also imply that the default line should be working, unless the FPM handlers are not working properly or not all.


In short, the final conclusion is that your manual fix is NOT a good solution, since it

- does not tackle the root cause of the problem: the FPM handlers are not working, see my previous post to get them working
- involves a less suitable approach to passing requests to the backend

and, therefore, one can also safely state that your problems have nothing to do with the php_over_fpm.php file in micro-update 23 (MU23).

However, it can be the case that MU23 requires a manual "stop and start" sequence of the FPM handlers, but even that is often not required.

I sincerely hope that all of the above helps and expains a little bit.

Regards

 

[OGR]

@OGR
Note that your statement actually speaks of "reinserting" a line equal to

ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:///var/www/vhosts/system/sub.domain.tld/php-fpm.sock|fcgi://127.0.0.1:9000/var/www/vhosts/domain.tld/sub.domain.tld

with this line probably being the line associated with your comment "extract the previous configuration style from another server", i.e. this line is presumably previous configuration.

Also note that the default line (in php_over_fpm.php), as associated with micro-update 23 (MU23), is equal to

SetHandler proxy:<?php echo $VAR->domain->physicalHosting->fpmSocket ?>|fcgi://127.0.0.1:9000

and this is a templated line, meaning that you do not have to make changes to every "plesk.conf.d/vhosts/sub.domain.tld.conf" file.

The "ProxyPassMatch" line is from an earlier version of Plesk before MU23. This is the config that works. The "SetHandler proxy" line is the one created by the MU23 template which doesn't work. So I don't have to "change" the "SetHandler proxy" lines, but I need to comment them out (or I would need to empty the "fpm_over_php" file).

@OGR
I can only say, when comparing your line with default line (in php_over_fpm.php), that

1) your manual fix contains a mistake: let´s hope that you made a typo error by adding /var/www/vhosts/domain.tld/sub.domain.tld to the end of the line, but even though it should not be there, the type does not really matter, as I will explain later.

2) your manual fix contains the ProxyPassMatch instead of SetHandler: this is not NOT a good solution, as I will explain below.

My fix is not "insert some random stuff". It is "reinsert what Plesk did before MU23". This is exactly the configuration that Plesk created on another server running Plesk 12.5.30 MU22, with the path adjusted for this subdomain. The "ProxyPassMatch" line ends with the document root (for a subdomain Plesk by default creates no httpdocs directory, the subdomain only consists of the document root). As a matter of fact, I had a mistake in the line during testing, which yielded "file not found" in the browser. After correcting the paths the FPM is now working.

@OGR
... many true facts about FPM ...
and these facts also imply that the default line should be working, unless the FPM handlers are not working properly or not all.

...which it doesn't. I did not interpret anything about what the configuration lines mean. I just reverted the configuration to the one that would have been created with an earlier version of Plesk (the "+" lines" and that happens to be working, while the new style (the "#" lines) does not. Perhaps the new style from the template is missing the information about the document root at the end, which is a wild guess. I will test that and report back later.

Update: No, that did not help. The "SetHandler" configuration block doesn't work at all. The result with it commented out (and also the "+" lines commented out) is the same as if it wasn't there at all.

 

[OGR]

Guys, it would be more efficient if you submit support ticket about this problem with FPM Application served by Apache here - https://cscontact.plesk.com/form/32/?Product=Plesk
Our developers will check this issue in the scope of the support ticket.
Thanks.

That doesn't work. The Plesk licenses are from "Plesk partners", and I am for sure not jumping through the hoops of contacting my german server provider in the faint hope that they will contact your developers. I encourage you to create the ticket for us and provide the developers with a link to this thread, as it contains enough information to narrow down the problem.

Kind regards,

OGR

 

[trialotto]

@OGR,

You stated

Update: No, that did not help. The "SetHandler" configuration block doesn't work at all. The result with it commented out (and also the "+" lines commented out) is the same as if it wasn't there at all.

To be honest, if you had read my post carefully, you could have known that adding something after |fcgi:// is ignored in the case a socket is specified.

If you want to resolve your problem, just try the steps in my previous post.

If you want to use the ProxyPassMatch directive, that is fine too, but be aware of the facts that:

- any new micro-update or upgrade can break your manual fix,
- any failure in the fpm handlers is left unresolved,
- a penalty on performance exists (this "performance penalty" will be troublesome in the case of many domains and can even shutdown your Apache server)

and the above is just a rough outline, there are many other things to consider.

I would strongly recommend that you read up about the proxy directives in the Apache documentation.

Regards...

 

[OGR]

To be honest, if you had read my post carefully, you could have known that adding something after |fcgi:// is ignored in the case a socket is specified.

This is proven false by the fact that putting the wrong path at the end of the line yields "file not found" in the browser while putting the correct path works. And even if putting somehting at the end isn't supposed to make any difference: Don't tell me that, tell it to the Plesk developers, because before MU23 there was this:

admin/conf/templates/default/domain/domainVirtualHost.php:155:
ProxyPassMatch ^/(.*\.php(/.*)?)$ <?php echo $VAR->domain->physicalHosting->fpmSocket ?>|fcgi://127.0.0.1:9000<?php echo $OPT['ssl'] ? $VAR->domain->physicalHosting->httpsDir : $VAR-  >domain->physicalHosting->httpDir ?>

[...] If you want to resolve your problem [...] If you want to use the ProxyPassMatch directive

I do not consider this my problem, because I just seconded the report from BSMenny. I consider this a Plesk problem. From the moment where I'm not the only one with the problem there is a pattern. And I do not "want" to use the ProxyPassMatch directive, it is just what Plesk itself was using before MU23. If you clearly read my answer, then you can see that I did not invent any of the fix. I just pointed out the problematic changes in the Plesk templates and that reverting the created configs to the previous version solves the problem. It shouldn't be my task to find the source of the problem, but I did it anyway. Now it is up to the Plesk developers to either revert the changes introduced with MU23 or make the new version work. After all, me trying to move those changes to a "vhost.conf" just calls for more users to experience the original problem.

I don't know why the new version doesn't work. The socket file is there, the "IfModule" and "Files ~" directives seem fine, the FPM service is running, but it still behaves like those lines weren't in the file at all.

The new template produces configs that do not work. Yes, I did stop/start the FPM services (and the service does work). I also did stop/start the Apache2 (which is the right one to restart after changing the domain config file) and NGINX services, to no avail. Yes, "mod_proxy" is installed and enabled (the two fields "proxy" and "proxy_fcgi" look just like in BSMenny's screenshot). In the end, the new template produces a config where it seems as if the lines weren't there to begin with. Commenting them out produces the very same result.

 

[OGR]

Intermediate solution: Adding the following to the "additional directives for HTTP(S)" under the "Apache & nginx" settings works:

<IfModule mod_proxy_fcgi.c>
    ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:///var/www/vhosts/system/domain.tld/php-fpm.sock|fcgi://127.0.0.1:9000/var/www/vhosts/domain.tld/httpdocs
</IfModule>

That of course needs to be adjusted with the correct paths for the domain and creates a "vhost.conf" file. This needs to be put into both the "HTTP" and "HTTPS" text fields. This is the exact "ProxyPassMatch" code segment that was removed from the domain template with MU23. Leaving the snippet from the "fpm_over_php" file active does no harm since it didn't work anyhow in the first place.

If I'd had to leave this in there for all domains that would really be annoying, just like with Firefox when the developers remove some nice feature again and you are installing the 25th add-on to restore functionality that shouldn't have been changed or removed in the first place.

 

[Lloyd_mcse]

@OGR did you have to do this when installing MU23...

https://kb.odin.com/en/128398

One machine I did and haven't had a problem with FPM, the other gave no issue during the update but gave me the same issue as you are having here.
Maybe that will help shed some light on what is going on here, because that is the only difference between the two machines.

Anyway just a thought.
Kind regards

Lloyd

 

[trialotto]

@OGR,

It really seems to be the case that you are confusing yourself (and this is being said with all good intentions, no personal offense being intended).

And it really does not help me to help you, what the general idea of this forum should be: forum members helping each other.

At this moment, there are two facts:

1) both the SetHandler and the ProxyPassMatch directive should be working (except for the cases that Apache version is not version 2.4.9 or later),

2) you have some issue with PHP-FPM handling of requests.

You stated

I don't know why the new version doesn't work. The socket file is there, the "IfModule" and "Files ~" directives seem fine, the FPM service is running, but it still behaves like those lines weren't in the file at all.

The new template produces configs that do not work. Yes, I did stop/start the FPM services (and the service does work). I also did stop/start the Apache2 (which is the right one to restart after changing the domain config file) and NGINX services, to no avail. Yes, "mod_proxy" is installed and enabled (the two fields "proxy" and "proxy_fcgi" look just like in BSMenny's screenshot). In the end, the new template produces a config where it seems as if the lines weren't there to begin with. Commenting them out produces the very same result.

The essence of any change in templates is that these templates (and the changes therein) are not applied, unless "the machine is told do so".

I must admit that I changed the PHP versions continuously (in order to reproduce your issue on all PHP versions), implying that the new template has been enforced.

That resulted in applying the SetHandler directive successfully, so I am not sure whether you already tried to switch PHP versions (and revert back to the original PHP version).

Anyway, I will end my contribution to this topic thread, since there should be no reason to assume that a bug is present and/or that KB128398 has to be applied.

Regards....