I’ll bet a million dollars I don’t have that you have mod php installed. If you do, get rid of it.
1 Like
how can i check?
from googling i found that following will work only if mod_php is installed:
print_r(apache_get_modules());
but i don’t see anything, so i assume your guess wasn’t right.
What happens when you run Re-Check Configuration? Also might try Validate Virtual Servers to see if there are any clues about what’s gone wrong.
mod_php is always our first guess here because so many people break PHP by installing it. It’s the most common problem here (maybe tied with DNS misconfiguration).
I run Re-Check Configuration every time when i change something. In this case it doesn’t help.
validation shows:
Apache website : PHP FPM configuration error found : Apache config port 8000 does not match FPM config /var/php-fpm/160897975738280.sock
can someone tell me how to check if mod_php is installed?
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?
In PHP Options i changed execution mode to Disable and back to FPM.
Idk if it did something, but " PHP FPM configuration error" is gone.
Now validation shows:
Apache website : An IPv6 DNS record domain.com with address ::1 exists, but this virtual server does not have IPv6 enabled
This is certainly not a common issue. But we could definitely work around it. @Jamie, is there a reason why we don’t force overwrite listen= with whatever set in the template on PHP version change?
We don’t want to forcibly change the user’s chosen FPM socket / port mode.
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?
1 Like
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?
1 Like
I’m not sure how the user could have ended up with a mismatch between the Apache config and the FPM config. However, switching to a different PHP mode and then back again to FPM should fix it…
1 Like
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
Please open new topics for new questions.
@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.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.
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
Tested on Ubuntu 22.04.
2 Likes
Thanks, I’ll take a look into this …
Ok I see the bug that causes this, and will fix it in the next Virtualmin release (7.6)
3 Likes
Tested it and this really works correctly now! Thanks, Jamie!
1 Like