• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

PHP pages no nolger load after 12.5.30 MU#23 update

First of all, thanks for alle the help, even if nothing fixed it.

In short:
  • I had no error message for the MU23 update. I applied KB128398 anyway, which yielded no errors. After that, the problem persists.
  • The ProxyPassMatch directive is working, the SetHandler directive is not. I restarted the FPM and other services many times, switched PHP versions, switched the type of PHP handling, to no avail.
  • Of course I experienced the templates being applied, which did overwrite my changes (as expected) and broke "PHP-FPM via Apache" again (all other variants are working).
  • That's why I added the vhost.conf solution of additionally using the ProxyPassMatch directive.
I do not know what I can do now to analyze the problem any further. The whole server was "use default Ubuntu 14.04 LTS, install Plesk and be done". Which worked, until MU23.
 
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
Please read PM from me.
 
Hi,
is it only affecting Ubuntu 14.04?
If so, I'll try and reproduce the issue and submit a ticket.
I still have some left :p

Regards,
Kristian
 
Same issue here with two VPS running on CentOS 7.1.
Both server where unable so serve websites after the mu23 update, at 24 feb 03:45 (GMT +2).

I have another VPS with CentOS 6.6 and this got the mu23 update at 22 feb 03:21 (GMT +2). This one had no issues after the update.

My quick fix was to reboot the whole VPS and after that everything was working fine.

I changed all servers to the "Late adopter release" update plan. Hopefully servers won't go down again after an automated update.
 
@Everyone,

Everybody is stating facts about their own personal situation/solution and that certainly does not help to identify a general solution, that can be used in a micro-update.

For that reason, I will be summarizing the results a bit later, but first I have to ask some necessary questions.

@Lloyd_mcse and @BSMenny: can you provide the package details (run: dpkg -l | grep libapache2-mod-proxy)?

Can you confirm that it is 2.4.7-ubuntu14.04.16022012 on the updated machines, that did not encounter any problems?

@Lloyd_mcse and @BSMenny: can you provide the package details (run: dpkg -l | grep psa-phpfpm-configurator)?

Can you confirm that it is 1.0.0-ubuntu14.04.build1205160218.11 on the updated machines, that did not encounter any problems?

@Timo002: can you provide the package details (for both the phpfpm configurator and mod_proxy) for all your CentOS systems?

@Timo002: I am particularly interested in the CentOS 6.6 machine, which should have a different Apache version. Can you give some package details about Apache?

@OGR: can you also provide some of the package details?


In general, it seems to be a dependency conflict, but this conflict occurs in rather remarkable circumstances:

a) MU23 is including a patch to resolve the conflict, associated or following after some previous install or update actions: MU23 should actually prevent the issue from occurring!

b) Whenever using sockets, ProxyPassMatch and SetHandler directives should not work on an Apache 2.4.7 (used by default in Plesk): for that reason (and other reasons), Plesk is probably provided with the libapache2-mod-proxy-psa package, even though we would be better off with an Apache related micro-update!

c) the psa-phpfpm-configurator should not be the root cause of the problem: the package libapache2-mod-proxy-psa is!

d) KB128398 is essentially resolving an installation problem, associated with an upgrade of the libapache2-mod-proxy-psa package: however, it seems to be the case that the intended package version (i.e. 2.4.7-ubuntu14.04.16021710) causes some issues, if and only if the intended patch for before mentioned problem (i.e. MU23) is working properly.


In short, from the above it follows that

- a specific version of libapache2-mod-proxy-psa is the root cause of the problem, (OR)
- if and only if the intended patch from MU23 is not working properly, installation issues occur that prevent that a proper version of libapache2-mod-proxy-psa is installed.

For that reason, I am asking about the package details, since that can reveal which of the two problems is causing all of the PHP-FPM related issues.

Regards....

PS I still would like to see an Apache update, instead of using updates for the libapache2-mod-proxy-psa package. It would certainly prevent any future issues to occur.
 
Hi trialotto,
yeah that's right, those are the versions that are now installed, I'm not sure what versions were installed before unfortunately.

Though it looks like these were the previous versions...

libapache2-mod-proxy-psa_2.4.7-ubuntu14.04.16022012_amd64
And
psa-phpfpm-configurator_1.0.0-ubuntu14.04.build1205150819.14_amd64

Hopefully someone else will confirm that.

And yeah, I only got the error when installing MU 23.
Well, I upgraded my first server last week through the GUI Autoinstaller, which gave the errors noted in the KB. However, the one that gave me this error, upgraded after I clicked Install from the Plesk homepage - which obviously happens in the background, but I didn't see any errors in the logs.

Kind regards

Lloyd
 
@Lloyd_mcse

So, if I am not mistaken, you have AND had the correct libapache2-mod-proxy-psa package version, but the wrong psa-phpfpm-configurator package version?

Seems to be the case that you had a dependency conflict, due to psa-phpfpm-configurator, in which case KB128398 is indeed a solution (even though a more easy solution exists, in the sense that it seems to be working to just update the psa-phpfpm-configurator package, without any removal of packages first. Note: updating with dependency resolving).

The above would imply that your situation is different from the situation, applicable to other forum members: they have an issue with libapache2-mod-proxy-psa (and the version thereof).

It becomes a little bit annoying that packages are actually updated "at random or not at all".

@IgorG, @custer, can we agree to put this "random update" issue under investigation as a potential issue (or even bug)?

Regards.....
 
@trialotto Sorry my mistake I copied the wrong mod-proxy,

Should be...
libapache2-mod-proxy-psa_2.4.7-ubuntu14.04.15072015_amd64
and
psa-phpfpm-configurator_1.0.0-ubuntu14.04.build1205150819.14_amd64

So those would have been the previous versions I was on.
 
@Lloyd_mcse

No problem, the "conclusion" in my previous now changes a bit, but the essence remains the same.

The essence is and was that KB128398 has to be applied in some situations, in order to enforce an update of packages, implying that the patch in micro-update 23 (MU23) is not working properly, for at least the before mentioned situations (that still have to be identified more uniquely).

After all, MU23 is (amongst others) intended to allow overwriting/replacement of (specific) existing packages (and that did not happen in your case, requiring the fix of KB128398).

Some feedback by @BSMenny, @OGR, @Timo002 would still be much appreciated.

Regards...
 
Hi, the solution from Lloyd worked for me (Ubuntu 14.04), after spent more than 1500 € of adwords since problem comes with update... for nothing !!! on few domains for customers (all with FPM apache), and when changet to NGINX it worked (when I see the problem), with patch described, it work normal like before with FPM :

Right, I just applied KB128398 to my server with this issue and FPM is now working :)
I hope this helps someone with the issue.
Kind regards

Lloyd​
 
@trialotto,

See the details below:
  • Server 1: Websites went down after MU23. I don't know what exactly went down. Plesk was working fine, website running on the VPS where all down. I though nginx was not running, started it with systemctl start nginx, no success.
  • Server 2: Websites went down after MU23. I don't know what exactly went down. Plesk was working fine, website running on the VPS where all down. I though nginx was not running, started it with systemctl start nginx, no success.
  • Server 3: No issues after MU23 update.

Server 1:
OS: CentOS Linux 7.1.1503 (Core)‬
Plesk: 12.5.30 Update #23, last updated at Feb 24, 2016 03:50 AM
$ rpm -qi psa-phpfpm-configurator
Name : psa-phpfpm-configurator
Version : 1.0.0
Release : cos7.build1205160218.11
Architecture: x86_64
Install Date: wo 24 feb 2016 03:49:43 CET
Group : Networking/Daemons
Size : 138
License : Commercial license
Signature : DSA/SHA1, do 18 feb 2016 06:27:43 CET, Key ID bd11a6aa914bdf7e
Source RPM : psa-phpfpm-configurator-1.0.0-cos7.build1205160218.11.src.rpm
Build Date : do 18 feb 2016 06:27:22 CET
Build Host : bcos7x64.plesk.ru
Relocations : (not relocatable)
Packager : Parallels <[email protected]>
Vendor : Plesk
URL : http://www.parallels.com/
Summary : Plesk v1.0.0 configurator for php-fpm
Description :
Provide installation and configuration of php-fpm;

$ rpm -qi libapache2-mod-proxy
package libapache2-mod-proxy is not installed

Server 2:
OS‪: CentOS Linux 7.1.1503 (Core)‬
Plesk: 12.5.30 Update #23, last updated at Feb 24, 2016 03:42 AM
$ rpm -qi psa-phpfpm-configurator
Name : psa-phpfpm-configurator
Version : 1.0.0
Release : cos7.build1205160218.11
Architecture: x86_64
Install Date: wo 24 feb 2016 03:41:31 CET
Group : Networking/Daemons
Size : 138
License : Commercial license
Signature : DSA/SHA1, do 18 feb 2016 06:27:43 CET, Key ID bd11a6aa914bdf7e
Source RPM : psa-phpfpm-configurator-1.0.0-cos7.build1205160218.11.src.rpm
Build Date : do 18 feb 2016 06:27:22 CET
Build Host : bcos7x64.plesk.ru
Relocations : (not relocatable)
Packager : Parallels <[email protected]>
Vendor : Plesk
URL : http://www.parallels.com/
Summary : Plesk v1.0.0 configurator for php-fpm
Description :
Provide installation and configuration of php-fpm;

$ rpm -qi libapache2-mod-proxy
package libapache2-mod-proxy is not installed

Server 3:
OS‪: CentOS 6.6 (Final)‬
Plesk: 12.5.30 Update #23, last updated at Feb 22, 2016 03:22 AM

$ rpm -qi psa-phpfpm-configurator
package psa-phpfpm-configurator is not installed

$ rpm -qi libapache2-mod-proxy
package libapache2-mod-proxy is not installed
 
@Timo002

You should run the command rpm -q libapache2-mod-proxy-psa, to be sure. Can you do that and provide the output?

In general, one has to be aware of the following:

1 - the package libapache2-mod-proxy-psa is used to introduce a proper mod_proxy on all OSes and/or for all Apache versions, supported by Plesk
2 - the package libapache2-mod-proxy-psa is completely separate (and different) from the mod_proxy module, included in apache2-bin (Ubuntu) and httpd (CentOS),
3 - there is or has been an upgrade error: packages are not installed correctly or not at all, due to dependency conflicts (see point 2) and/or overwrite failures,
4 - micro-update 23 (henceforth: MU23) essentially implements the SetHandler directive, for which a proper version of libapache2-mod-proxy-psa is required,
5 - any failure in MU23 and/or implementation of MU23, will lead to a package error: the old libapache2-mod-proxy-psa does not support the SetHandler directive (apparently).

The above implies that, given the results on your various servers, it is very likely that
- servers 1 and 2 have the wrong version of libapache2-mod-proxy-psa OR no libapache2-mod-proxy-psa at all, which causes Apache (version 2.4.6 on CentOS 7.x) to "use" the default mod_proxy (as included in httpd on CentOS 7.x), which default module cannot handle the SetHandler directive,

- server 3 has no upgrade conflicts and the proper version of libapache2-mod-proxy-psa (or none at all),

but I am not sure, I actually need the output of the before mentioned command to be sure.

Note that I am particularly interested in server 3.

Regards....
 
Server 1:
$ rpm -q libapache2-mod-proxy-psa
package libapache2-mod-proxy-psa is not installed

Server 2:
$ rpm -q libapache2-mod-proxy-psa
package libapache2-mod-proxy-psa is not installed

Server 3:
$ rpm -q libapache2-mod-proxy-psa
package libapache2-mod-proxy-psa is not installed

To be honest, I don't understand a bit of what you are saying in point 1 through 5 o_O
 
@Timo002

Not a problem ;)

Here is the simpler version:

- do nothing on server 3 (unless you need FPM and/or mod_proxy),
- install package libapache2-mod-proxy-psa on servers 1 and 2 (and restart the psa service, to be sure).

By the way, I would strongly recommend to use the Plesk autoinstaller to install any packages.

Hope the above helps.

Regards...
 
@trialotto

I have no idea how to install those package by using the Plesk autoinstaller.

Another question, why should I install these packages? Both servers are running fine after I restarted them. Will they "crash" again after a new update if I don't install these packages?
For now my feeling is like: "if it ain't broke don't fix it"
 
@Timo002

You are absolute right in the remark "if it ain´t broke don´t fix it".

However, any update (of any kind) CAN make some issues reappear. This is not a certainty at all, it can also be the case that updates are applied without any problems.

It really depends on the update and the packages involved.

The actual problem is that you, if you decide to use FPM, will encounter a problem, since the proper packages are not installed.

Nevertheless, it would not make any sense at all to install packages you presumably are not using and/or have not been using.

In short, stick to you original plan: do not change the system.

Regards...
 
Please read PM from me.
Sorry for returning so late to the topic. I checked out with a cold and just managed to get back to the topic just now.

I cleaned everything up on the server, rebooted it and at some point it just started working. The only problem is that now I just can't figure out what fixed it. This now seems like a Heisenbug, the more you look for it, the less you find out. Now it will be interesting, what the next server does,which isn't running Ubuntu 14.04 LTS but Debian 8.3. We'll see.

Any way, thanks to everybody for all the support!
 
Back
Top