Since few days I’m experiencing a issue with PHP-FPM (I’m only using the Remi 7.4.9 one): it stops to work after few hours since any update that requires reboot, After rebooting, I see the PHP-FPM service listed under the SERVER STATUS tab, but some time after it disappears from that tab and websites using it stop to works. The only way I have to get is listed again under the server status tab is to run re-check configuration wizard. This is an annoing issue: could someone suggest me a fix, if any?
The affected vms run on ESXI 6.7 latets patch, Centos 7 latest build, Virtualmin latest build
Thank you in advance. Regards
1 Like
I see the same behavior with PHP 7.3 and 7.4 on CentOS 8. Both are enabled at boot time but often don’t start. One or the other stopped recently after a PHP update.
In a terminal if you type systemctl status php-fpm
and it reports php-fpm.service; disabled;
you need to at least run systemctl enable php-fpm
But if your system is like mine and the service is enabled and continues to not start and run as expected, there’s some other problem. I’ll post again if I make any progress with it.
With the RH PHP 7.2.24 on CentOS 7, running systemctl status php-fpm on my system will always report “failed.” But running the command for the RH-specific PHP implementation (for example, systemctl status rh-php72-php-fpm.service ) will produce a correct response.
Similarly, I found that PHP 7.2 PHP-FPM was not starting on boot. It didn’t even appear as an option in Webmin -> System -> Bootup and Shutdown nor in Virtualmin -> Dashboard -> Servers Status until it was manually started. Running systemctl enable rh-php72-php-fpm.service seemed to fix all of those problems.
Richard
2 Likes
Richard is right. If you’re using a different PHP-FPM package that has a different service name, you must use that service name to start/stop/enable/disable the service. php-fpm.service is completely separate from rh-ph72-php-fpm.service.
I don’t know anything about the Remi packages, but if they’re using different paths (and they definitely are, if they can coexist peacefully with the system PHP packages), you need to accommodate that.
1 Like
In my case PHP 7.4 replaced default/global 7.2 and systemctl enable php-fpm is proper usage. PHP 7.3 is extra and installed to an oddball location. It requires systemctl enable php73-php-fpm.
Irregardless, one or both will stop unexpectedly and don’t always start on boot. systemctl start php-fpm and/or systemctl start php73-php-fpm brings them back. And both always show services as enabled with systemctl status.
The same thing happens with Ubuntu 20.4 installed with fpm by default but the problem is with apache, I did not install php or apache from another source, the php and apache was installed by virtualmin and when I restart the server almost every time but not all it appears that it is running apache but actually it is not exempt and I have to restart apache manually.
In addition, the php presents some kind of problem (inconsistency) at times it does not progress, it is as if it paused and sometimes it stops responding. I would like to provide data on what is wrong and not just say that it fails, but I do not have the knowledge to do, the only thing I can contribute is the following.
[Sun Aug 09 20:53:33.545171 2020] [proxy_fcgi:error] [pid 539845:tid 139682646050560] [client 172.69.71.163:15116] AH01079: failed to make connection to backend: localhost, referer: https ://myweb.com/en.html
[Sun Aug 09 20:53:33.624065 2020] [proxy:error] [pid 539846:tid 139683166136064] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed
And this
[Sun Aug 09 02:25:00.689588 2020] [proxy_fcgi:error] [pid 227710:tid 140305055586048] (104)Connection reset by peer: [client 172.68.50.47:34260] AH01075: Error dispatching request to :
[Sun Aug 09 04:24:24.155022 2020] [proxy_fcgi:error] [pid 227711:tid 140305231546112] [client 172.69.63.250:51344] AH01067: Failed to read FastCGI header
@rechy2k that’s a completely unrelated problem. proxy_fcgid is not at all related to php-fpm. Open a new topic, if that problem persists for you.
Thanks, your suggestion has solved the problem in my case 
Simply runned ‘systemctl enable php74-php-fpm.service’ to get the service running again at boot.
3 Likes
Maybe disabling, stopping, re-enabling, and starting them might help? Possibly the symlinks haven’t caught up to the news.
Richard
I’ve already tried that. The more annoying problem is PHP-FPM stopping when the server has been up a while. When I figure that out maybe it’ll change its mind about starting on boot.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.