There is a bug in Virtualmin with PHP-FPM when creating a new or cloning virtual host

OS type and version Debian Linux 10
Webmin version 2.021
Virtualmin version 7.7

There is a bug in Virtualmin with PHP-FPM when creating a new or cloning virtual host.

When restarting php-fpm (sudo systemctl stops php8.1-fpm.service for example, then I get an error:
Job for php8.1-fpm.service failed because the control process exited with error code.
See “systemctl status php8.1-fpm.service” and “journalctl -xe” for details.

After searching and logs, what is happening is that the last user.conf is not deleted from the /etc/php/8.1/fpm/pool.d/ folder. If I manually delete it (example 1593578529637410.conf) and start PHP-FPM again.

Also, it is not possible to add a new Virtual Server because php-fpm will not start it with this error.


Why would the pool file get deleted on restart? Restarting PHP doesn’t delete the pool aka config file for a domain, otherwise you’d lose custom configurations for that domain.

It’s possible there’s a typo or error in the config causing the restart to fail, but deleting the file isn’t really the answer.

Hello friend,
I’m forced to delete 1593578529637410.conf for example, otherwise php-fpm won’t start. The impression I have is that when restarting php-fpm it does not update the /pool.d/xxxxxxxxxxxxx.conf file, since when creating or changing any configuration in the domain, Virtualmin does a reload.


I confirm I have intermittently encountered this issue on Debian 10 systems


Typically when you make a change to a config file in general, the daemon or server that uses the config needs to reload or even restart in order to read the changes as they are often loaded into memory.

However, this still doesn’t explain why you are deleting the config file, as doing so then restarting/reloading means PHP would never see the saved changes as you just deleted the file containing them.

I have to delete the domain’s xxxxxxxxx.conf file because php-fpm doesn’t go up and all other domains go down. When I do that this file is recreated and the php-fpm service starts normally.


Which means there’s likely an error in the config. But now after deleting you also deleted the changes you were making. You need to figure out what the error is instead of deleting the file. Perhaps compare the config against a working one.

1 Like

what @tpnsolutions said. there’s (most probably) an error in fpm config.

Good morning guys,
Okay, I’ll do a check on the PHP-FPM settings.

Thank you all.

Hello good morning everyone.

Regarding the problem of PHP-FPM not restarting or starting after removing a domain account, it is that the file “example 1593578529637410.conf” does not have the correct permissions.

The file corresponding to the domain account “Example: /etc/php/8.1/fpm/pool.d/1593578529637410.conf” has the “root” permission and not the domain account, then when the account is removed it cannot restart by account from that.

In my case, I repeat, in my case I change the permission of the 1593578529637410.conf file for the domain account user and everything happens normally.


Thanks for letting us know. :+1:

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.