So, I seem to recall I’ve seen someone else with this problem. There’s a mismatch in the config. It’s trying to connect on a port, but FPM is setup to use a socket (sockets are usually better, but they need to match).
@Ilia is this a known issue? If I’m correct in remembering that this is an issue I’ve seen from someone else, is it something wrong in Virtualmin’s FPM configuration?
Yes, but the question is how it ended up this way? It doesn’t seem like a user would intentionally do it, and I know I just saw someone else with the same issue recently…so, something is happening somewhere to make it happen…I’m not ruling out user error, but I also don’t think we can rule out a Virtualmin bug, either?
Yeah, it would help a lot if we could get the steps to reproduce this issue. Perhaps, the domain was restored from a backup, from the system with PHP-FPM using ports to the new system where sockets are used by default…
And I don’t see why not, because we have to respect the template’s settings. That’s what the templates are for, right?
suddenly i was able to switch PHP version via PHP Options.
I didn’t even had to modify www.conf of PHP 8.0
I assume it’s because I changed execution mode to Disable and back to FPM?
as it was only thing i did additionally. Previously nothing was working.
maybe someone help me with following error? As i understand I have to enable IPv6, right? Where exactly is this option, to enable IPv6? Apache website : An IPv6 DNS record domain.com with address xxxx:c205:2047:5702::1 exists, but this virtual server does not have IPv6 enabled
@Jamie, I would like to suggest to only rely on the template data for determining listen=. It’s a wonderful feature to remember previously set PHP versions for each mode (simply because a user can choose it), but remembering listen= shouldn’t be remembered, I think, as there is the template for that (and a user cannot choose it on PHP Options page), and therefore shouldn’t the template be the source of truth for which listen= we set?
Also, improving port clash fixes would be something else to fix (if there is really an issue there). I will see if I can repro this issue.
I have been trying to reproduce this issue with ports clash on CentOS 7 to Rocky 8 and on Ubuntu 20.04 to 22.04 restores, and I couldn’t. It seems to work just fine.
For example, if a template isn’t standard, then the template is restored, ports are used for FPM connections just as set on the template, and ports clash is resolved (as there were other websites on the source system using FPM ports connections). If a default template on source system is set to use FPM ports and target system uses sockets, then restored domain is also starts using sockets, which is great.
I wish @jurgis I could help more, but I just cannot reproduce a problem.
@Jamie, I have finally discovered and reproduced this bug. The problem pops up when changing FPM listen mode (port vs socket) in the template for existing virtual server, and then changing PHP version for the virtual server.
Reproducing it is easy:
Create a virtual server with default options (and template is set to listen on socket for FPM)
Then change FPM listen from socket to port on the template
Then change PHP version for the virtual server
Bug is there by this point, where web-server (Apache) config was not updated to FPM listing on the port, and it keeps using the socket