Control Web Panel
WebPanel => CentOS 7 Problems => Topic started by: centosuser$$ on November 16, 2020, 01:03:55 PM
-
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?
-
By reading logs. ::)
-
Cynic by name and cynic by nature...
Obviously but where is the path for the logs...
-
Cynic by name and cynic by nature...
Yup!
When in doubt.. revert to *nix basics
ls -l /var/log
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.
-
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..
-
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
<?php phpinfo(); ?>
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.
-
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.
-
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.
-
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?
-
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
-
Guys, make sure you have CWPpro activate.
Also, you can try to rebuild VirtualHosts without PHP-FPM and then go back to PHP-FPM.
-
correction removing httpd did also removed my init-scripts.
This worked for me:
rpm -e httpd --nodeps --justdb
rpm -e httpd-tools --nodeps --justdb
yum reinstall cwp-httpd