PHP-FPM error

[centosuser$$]

I have been using PHP-FPM 7.3.21 without any problems.

Today I updated a whole bunch of packages and afterwards PHP-FPM began to cause errors with my wordpress website.

I switched to the PHP-CGI version and that works.

How can I diagnose what is up?

[cinique]

By reading logs. 

[centosuser$$]

Cynic by name and cynic by nature...

Obviously but where is the path for the logs...

[cinique]

Cynic by name and cynic by nature...

Yup!
When in doubt.. revert to *nix basics

Code Select Expand

ls -l /var/log

Code Select Expand

find / -name "*domlogs*" -print
Or you use the GUI given to you by the developers: login as user and select logs. Though this is likely only to give a partial story.
If the developers would see fit to reinstate the official CSF GUI, then you could also see the Apache log in real time, assuming that you  use Apache.

[centosuser$$]

Thanks... I was posting here because I had seemingly exhausted all options of finding where the output of errors when using PHP-FPM were being logged.

I will take a look at what you recommended but up until now I cannot find the output that can show why my website is down when using PHP-FPM

I am using Apache- Nginx- Varnish

And I have looked at error logs and access logs for all of them but nothing indicates an error..

[cinique]

Back to web basics, this time.
Likely you won't have disabled this method.. if your installed application doesn't have something similar.
Create a file in your user's public_html called for example myphpinfo.php

Code Select Expand

<?php phpinfo(); ?>

Code Select Expand

chown user:user myphpinfo.php
http://userdomain.com/myphpinfo.php
Scroll down or search for error_log
example:    /home/user/public_html/shop/Log/errors-20201116.txt  <- will depend on whether your application modifies the default.

[cinique]

P.S. Life is too short to debug the complexities of running such a stack. I used nginx reverse proxy for a couple of years and though useful, when problems arose it just created more headaches. Varnish just adds complexity. KISS philosophy - I am veering toward PHP-FPM, rather than suexec/su_php/suhosin/FastCGI.

[centosuser$$]

Yes I agree too complex :-(

I did find this though in my nginx output:

[Mon Nov 16 16:32:36.633747 2020] [proxy:error] [pid 19940:tid 139994467337984] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /opt/alt/php-fpm73/usr/var/sockets/xxxxx.sock (*) failed
[Mon Nov 16 16:32:36.633780 2020] [proxy_fcgi:error] [pid 19940:tid 139994467337984] [client xx.xxx.xx.xxx:44980] AH01079: failed to make connection to backend: httpd-UDS

xxxxx.sock is a user account.

[cinique]

You could try Googling the clearing of nginx reverse proxy cache, plus varnish cache, then rebooting. Though it may be a permissions issue.
My advice: stick with Apache/PHP-FPM and tune your database/Apache. Add an opcache/memcache/redis and you're good to go. Are the performance gains from the other approaches really worth it, if they're even noticeable by end users?

[dzseti]

I had a similar problem this morning.

It seems that Apache is using the wrong conf file (not the CWP one) and that /etc/init.d/httpd is missing

[Igor S.]

Guys, make sure you have CWPpro activate.
Also, you can try to rebuild VirtualHosts without PHP-FPM and then go back to PHP-FPM.

[thenob]

correction removing httpd did also removed my init-scripts.
This worked for me:

Code Select Expand

rpm -e httpd --nodeps --justdb
rpm -e httpd-tools --nodeps --justdb
yum reinstall cwp-httpd