but the latest sites have something like this.
<FilesMatch .php$>
SetHandler proxy:unix:/var/php-fpm/120499663718102.sock|fcgi://localhost
that would be okay if the service was working…
I check there is a file at /var/php-fpm A sock type…
but only the one I just made not the hundreds of others sites.
The system has php72, 74, 80 that you can pick but it doesn’t seem to work …
if I move a older site php version; it changes to the /var/php-fpm folder and then it stops working…
Okay, that makes sense. but the new sites are not working…
a phpinfo.php give this…
Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
I restarted httpd, php-fpm.service even the server at one point…
I need to get the new way working or get them back to the old, but what sockets to connect? where is that all set?
The system has 250 or so sites… All running php something… The other sites are fine…
only the new sites that the system has starting using /var/php-fmp for socks has it given issues.
So new site that has Unix socket and not a TCP socket fails… and now any change of the php version
changes to the Unix sockets and then the php on that site fails. and the /etc/php-fpm.d/file.conf has the new unix sockets listed.
It would be interesting to fix this issue, if we could reproduce it.
For you, to solve this problem, you can disable Unix sockets and use TCP instead for PHP-FPM in System Settings ⇾ Server Templates: Edit Server Template / PHP Options page.
I found the server template had a new option in the php config area. Was not they now it has a “Default” Unix port" or TCP… From default I picked TCP and the sites worked…
I can check this on my backup server if that will help. But I leaving that system as is…
Thanks
Don
That would help, as I am not sure what’s wrong, because on that front PHP-FPM with both Unix sockets and TCP ports works just fine for me. I spent hours today, trying to break it but that particular part worked just fine.
I discovered few Virtualmin PHP bugs but those maybe unrelated.
Well, maybe we can find out why when I changed the backup system it stayed the port.
so it broken a different way… It will not select the Unix port style, after making the change…
I expected it to break when I flipped to the unix port. SO
I when to the “Edit Server Template” (that server is using) and selected " Unix socket file " and saved…
changed the PHP version
/phpinfo.php working and showing the right version
and looked at the .conf file and it still shows
" listen = /var/php-fpm/164791058141993.sock "
This is running 7.1 Pro also…
So this one doesn’t even change it to the Unix file so that fix would never be tested…
( would you like access to this system for a day or so … LOL )
I am not sure I follow. Do you expect existing virtual servers change settings when changing a template options? If so, this is not the case, as most template options only affect newly created servers.
The Template does affect the servers when you change the php options. Or it does on one of the systems. The first I found it was doing a backup restore. (not new but restore a weekly over the top of a site) … Working site, restored php dead… after changed the template port setting for php, that fixed it.
So the template does have a lot to do with it… It seems after the site is made it goes back and looks at the template for the php settings changes… Well system IP-…235 does and the spare one IP-…199 doesn’t…
(PS: Jamie help be when I posted this in the private area, that is how I found the fix,)
I can also see that upon restore PHP-FPM virtual-server config port is not adjusted.
@Jamie, is this expected? This is quite likely that restoring virtual server would result in non working PHP for variety of reasons?
Can we simply checked for domain config php_mode option upon restore and if PHP is enabled for the domain that is being restored, could you first disable PHP and then re-enable it, so all stuck/outdated config options would be first cleared and then re-built based on existing system configuration (templates)?
I will run more tests tomorrow, but when I was running the tests earlier today, when restoring a domain didn’t fix TCP config either. I don’t think the bug was only related to a socket-file mode.