Ondřej Surý recently rolled out updates for the different PHP versions he is providing in his repos packages.sury.org, resulting in numerous packages updates, especially on servers where several PHP versions are installed.
After the updates, it looks like Virtualmin is loosing track of PHP-FPM’s configuration for every Virtual Server where Web Configuration > PHP Options > PHP script execution mode is set to FPM The page then shows the following warning message…
Warning! PHP-FPM configuration error found : No listen directive found in FPM config
Click Save button below to update the PHP-FPM configuration and correct this error
… and the PHP version field is showing the wrong PHP version. In my case, the field shows the latest PHP version (8.4.4) whereas the site itself was set to, and is still running, another version. So the PHP version of the Virtual Server has not actually been changed, it is just Virtualmin not showing the right one. Other fields like PHP service maximum sub-processes and Maximum PHP script run time are also showing wrong values (the default ones if I’m not mistaken).
Also note that this is not the first time this has happened, it is an issue I have been observing for several months. I am finally taking the time to report it on the occasion of the latest Surý updates.
Is there an explantation to this? A fix would also be appreciated since checking hundreds of websites is a real pain
Go to the “PHP Options” page, disable the PHP execution mode, and then re-enable it to FPM. Does it make your PHP app on the website functions properly?
I checked several of my servers after running updates to PHP and have experienced the same issue this time.
However, if it may help troubleshooting why this occurs in the Virtualmin interface (and not other control panels we use here), when this happened to me in PHP-FPM configuration error on all server's sites I ran some tests on a number of websites on several boxes.
I found that from within the websites affected, the proper version of PHP was actually running despite that error indication AND despite the indication that the box’s “default” PHP was in place.
When doing this, it leaves the website in the state of PHP 8.4 which was not what the original setting was (it was 7.4). Plus, this method requires one to set the proper PHP version if they know it and perform this manually on every site.
Setting the website manually to 7.4 (or whatever its original was if you know that while in the interface) and saving clears the issue.
Ilya, is there anywhere else in Virtualmin that stores what the PHP version was set for in a site?
I did this manually to hundreds of sites the last time this happened…
It looks like the Virtual Sever is running PHP 8.4.4 … but it is not! It is still running the PHP version that was previously set. It is easy to check: one just have to click on the PHP icon next to the PHP version to look at the phpinfo(). In my case, it shows this.
The website is actually running PHP 7.1, that is the version that was configured prior to the problem. And by te way @Ilia the site is running just fine, no problems there.
Moreover, if I click on PHP-FPM Configuration, I see this.
Virtualmin believing wrongly that the Virtual Server is set to PHP 8.4, it is searching for the following configuration file: /etc/php/8.4/fpm/pool.d/17328095172188054.conf The 17328095172188054.conf file does exist, but in /etc/php/7.1/fpm/pool.d/, not in /etc/php/8.4/fpm/pool.d/ My understanding is that Virtualmin “forgot” the PHP settings of the Virtual Server, somehow falls back to default configuration and expect the config file in the wrong folder, hence the error message on the PHP Options page.
Yes, unfortunately, we have seen this error before but could never understand what was triggering it. We had hoped that the latest Virtualmin versions would fix it. @Nico94, did you just upgrade?
Webmin was just upgraded, (along with all the PHP updates), not Virtualmin.
Yes, fortunately. So it seems like a minor issue … but unfortunately it’s more vicious than that because all the PHP settings that were customized (you know, the usual upload_max_filesize, post_max_size, etc. that are very often customized) are lost.
