@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
Facebook
Twitter
