PHP-FPM configuration error found : No listen directive found in FPM config

Nico94 · March 11, 2025, 11:12am

SYSTEM INFORMATION
OS type and version	Debian Linux 12
Usermin version	2.202
Virtualmin version	7.30.4
Theme version	23.02
Apache version	2.4.62
Package updates	All installed packages are up to date

Hi everybody,

I run into a problem similar (actually identical) to this one: PHP-FPM configuration error on all server's sites

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

Ilia · March 11, 2025, 11:47am

Hello,

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?

charlesworks · March 11, 2025, 3:56pm

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.

Hope that’s helpful someplace along the line.

charlesworks · March 11, 2025, 4:10pm

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…

Nico94 · March 11, 2025, 4:53pm

Yes precisely. Let’s have an example here. This it what I see on the PHP Options page (screenshot very similar to Charles’ one: PHP-FPM configuration error on all server's sites).

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.

Ilia · March 11, 2025, 5:15pm

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?

Does clicking the “Save” button fix the issue?

Nico94 · March 11, 2025, 5:33pm

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.

Ilia · March 11, 2025, 5:37pm

We store those in the Virtualmin domain configuration file, so they shouldn’t be lost. What makes you think they are lost?

On which OS was PHP upgraded? Did you upgrade via Webmin or SSH?

redlotusaustin · April 4, 2025, 4:53pm

Ubuntu 24 LTS
Webmin 2.303
Virtualmin 7.30.8 Pro
Updates applied from SSH and Virtualmin

I am also experiencing sites losing their PHP configs and displaying “PHP-FPM configuration error found : No listen directive found in FPM config”

Additionally, when trying to re-save the PHP options it will mangle the PHP block of the site’s nginx config and occasionally some nearby blocks, too.

I have manually edited the site nginx configs, so is it possible that not going through Virtualmin to set options is the cause of some problems?

Ilia · April 4, 2025, 4:57pm

Could you share an example of how you manually edited your Nginx config? It would help if you could show a before and after example, explaining exactly how it got mangled.

redlotusaustin · April 7, 2025, 5:50pm

Most of the things I’ve manually added are extra location blocks, caching, etc. and I can send specific examples, but I just had the problem happen on a site that hasn’t been customized at all, so I’ll use that to start with.

I went to PHP Options for a Virtualmin server and, even though I had recently changed the PHP version to test something, it showed the message that there was no PHP config found:

Since I knew what was about to happen, I copied the Nginx config for the server before clicking the “Save” button and, sure enough, trying to save a config resulted in the same error:

The problem is that it mangles the .PHP block and line(s) after it; from this:

location ~ "\.php(/|$)" {
        try_files $uri $fastcgi_script_name =404;
        default_type application/x-httpd-php;
        fastcgi_pass unix:/run/php/17225292001404792.sock;
}
fastcgi_split_path_info "^(.+\.php)(/.+)$";

to this:

location ~ "\.php(/|$)" {
        default_type text/plain;
        try_files $uri $fastcgi_script_name =404;
}
        fastcgi_pass unix:/run/php/17225292001404792.sock;

The default_type is wrong, the fastcgi_pass line is outside of the block, and the fastcgi_split_path_info line is completely gone.

Here’s an example of a block that has been customized; when the mangling issue happens it will remove all of the fastcgi_cache, add_header, etc. lines and change it to just like the above:

location ~ "\.php(/|$)" {
        try_files $uri $fastcgi_script_name =404;
        default_type application/x-httpd-php;
        fastcgi_pass unix:/run/php/172179666424630.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_cache REDLOTUSAUSTINCOM;
        fastcgi_cache_valid 200 301 302 60m;
        fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
        fastcgi_cache_min_uses 1;
        fastcgi_cache_lock on;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        add_header X-FastCGI-Cache $upstream_cache_status;
}

The config files for before & after are attached, in case that helps (I had to rename them to .log to upload).
bldsecurity-nginx-config-pre.log (3.4 KB)
bldsecurity-nginx-config-post.log (3.4 KB)

This happens regardless of what version of PHP a server is using.

li9-hst_web-services · April 7, 2025, 6:23pm

I had a lot of problems with PHP-FPM version 8.3.19 and returned to PHP-FPM version 8.2.28 which is stabilized, using Apache.

charlesworks · April 9, 2025, 5:13pm

@Ilia - am still having this issue happen but cannot determine exactly what is causing it. On my Debian 12 system running Apache, I have ascertained that when the displayed “Warning!” (indicating that I must click the Save button below to correct this) is performed, I must first choose the default log location and correct PHP from the site, and all my distinct PHP settings for the site disappear and must be re-entered manually. It appears that the “Save” process in response to the message does not grab the existing settings and set the PHP back up like it was. I believe you mentioned those settings were (or should have been) saved in Virtualmin.

geotek · April 13, 2025, 3:57pm

I am observing the same issue on all of my Virtualmin servers. I am also using the Sury PHP repo and after each Debian 12 update some websites show the error “No listen directive found in FPM config” and the wrong PHP version in the dropdown list, while the actual PHP version is still correct. The PHP error log file is also shown as disabled.

In order to fix it, I must go through all websites, determing the running PHP version, select this version in the dropdown list, re-eanble PHP logging and click save. This is a real pain. Is there still no solution in sight?

Stegan · April 13, 2025, 4:09pm

Is this just another example of a server admin “off roading” and not just accepting the default PHP installed and approved/maintained by the OS?

not being an avid user of PHP (I just do not see the point of installing anything but that provided)

geotek · April 14, 2025, 8:13am

Hi Stegan,

our Virtualmin Servers are hosting websites running a wide variety of server applications, so we have to offer a choice of supported PHP versions matching the requirements of these apps. There are apps that are notoriously slow in accepting new PHP versions, so there is never one PHP version that fits all applications and all customers, considering that we have no control over the decision exactly when a server app will be updated.

Ilia · April 14, 2025, 8:59am

And, what is the last version of Webmin and Virtualmin you installed that led to this issue?

Stegan · April 14, 2025, 10:55am

the bane of an admin’s life!

in this case could this be related to the webserver in use (Apache) and the site’s use of htaccess?

geotek · April 14, 2025, 1:09pm

@Illia: All servers are running Debian 12, Webmin 2.303 and Virtualmin 7.30.8 now. Originally they received a fresh Debian 10 installation with Webmin and Virtualmin which were continuously kept at the newest versions respectively.

We are using the unmodified Apache versions that came with each Debian Version. About two years ago we switched all websites from mod-php to php-fpm, the problems appeared about one year ago, but I can’t remember the exact Virtualmin version when this started.

@Stegan: Even simple websites containing a single html file and no .htaccess file are affected.

Stegan · April 14, 2025, 2:48pm

thanks just guessing (wildly it seems ) I have only one Debian box (v12) and not come across this issue.