this issue was raised previously by another user some time ago and was caused by a different means to my find today, however, the issue clearly has never been correctly resolved and causes considerable problems for the Virtualmin system.
The reason it is such a huge problem...it takes out the entire server php-fpm x.x operations for any and all virtual servers using the same version of php-fpm!
Here is how i struck the issue (and i have encountered this twice in 3 days)
Virtualmin>Server Configuration> Move Virtual Server
i moved an existing virtual server wordpress.domain.com from a primary virtual server underneath a parent server with the same domain name (ie domain.com).
Virtualmin moved the server no problem, however as soon as it completes the move and then attempts to restart php-fpmx.x the php-fpm server fails to restart because it exited with an error code.
In checking the php.conf file for the new Virtual Sub Server wordpress.domain.com i have just created, i then goto...
virtualmin>Services>PHP-FPM Configuration>Edit Configuration Manually
It displays the following
[157298130131546]
user = flystanwell.com
group = wordpress
listen = 8012
pm = ondemand
pm.max_children = 20
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 5
php_admin_value[upload_tmp_dir] = /home/wordpress/tmp
php_admin_value[session.save_path] = /home/wordpress/tmp
php_value[memory_limit] = 16M
php_value[session.save_path] = /home/wordpress/tmp
php_value[max_execution_time] = 180
php_admin_value[upload_max_filesize] = 32M
php_admin_value[post_max_size] = 32M
The error is in the second line
group = wordpress
this group does not exist in Webmin!
The fix (which i have found on another forum/blogg is to change that line to read...
group = domain.com (where domain.com is a group the parent virtual server belongs too and which actually exists in Webmin)
This is a critical fix that needs urgently resolving as anyone who moves virtual servers (or migrates cpanel accounts where there is the possibility of similar domain names) will find that this bug will take out their entire php-fpm server (it will stop working until the error is fixed manually as i outline above). What is worse, if the user than changes the php-fpm version for the new virtual server where the group is wrong...it will also take out that php-fpm version as well. I ended up with all of my php-fpm servers offline (and thus all server websites running on php-fpm stopped functioning as well).
Dont forget to goto Virtualmin>Server Configuration>Website Options and just click "Save" (this will restart php-fpm for this virtual server and it should start working again)
I hope this workaround is something that others find useful.
Comments
Submitted by adamjedgar on Thu, 11/21/2019 - 20:47 Pro Licensee Comment #1
Submitted by adamjedgar on Thu, 11/21/2019 - 21:14 Pro Licensee Comment #2
Submitted by lexo_ch on Fri, 01/08/2021 - 12:37 Pro Licensee Comment #3
We just had this issue again also. It's extremely annoying and dangerous. We created a new website today and after it's been created it kills our whole server (all hosts configured to use PHP-FPM). This cost us 2.5 hours in Support today!!! We had to manually fix about 15 hosts which were corrupted after simply creating a new virtual host. Please please fix this!!!
Sorry to hear that. What is Webmin and Virtualmin version installed?
If you do
cd /etc/and rungit init && git add "*" && git commit -am "Initial backup"and later create a new, another virtual server, does this issue happen again? If so, what is the output ofgit diff? I realize that this is a production server but it would help if you could provide some details.What exactly you had to fix? What OS is this? What PHP packages are installed aside from default ones? Could you list them?
Usually, there is no reason to fix anything manually as you can always use CLI to bulk process all domains at once.
Submitted by lexo_ch on Fri, 01/08/2021 - 13:05 Pro Licensee Comment #5
Webmin Version: 1.962 (update to 1.970 ready but not yet installed - I don't want to kill our server twice at the same day) Virtualmin Version: 6.12 Pro
What I had to fix: When starting PHP-FPM it complained about wrong group being specified in the pool .conf file. As described above in the OP the system, once a domain is moved and group-name is changed, does not update the information in the PHP-FPM config. Thus the system, when being updated or when new hosts are being created, it seems to patch the existing full-working PHP files with wrong group names. So we had to find all broken files (based on modification date, system only messes up the ones it thinks are wrong but are in fact correct).
cd /etc && grep -R old-group-name
It did not find anything. Also sometimes, after creating a new vHost, PHP-FPM does not restart anymore because the listening port is still in use. As it seems the system does not check if there's already a service running at a specific port when setting up a new one. That was also one of the bugs we occured today.
About your GIT idea: I don't quite understand. We have no GIT repo running in /etc/ and I would not really like uploading anything from our core config directory to GIT. But maybe I don't quite understand what you mean.
Git is just to track on changes.
Virtualmin 6.12 is pretty outdated, the latest version is 6.14.
Submitted by lexo_ch on Sun, 01/10/2021 - 08:36 Pro Licensee Comment #7
I updated everything to newest versions. Same thing: After creating a new vHost the /etc/php/7.3/fpm/pool.d files are being modified with wrong (old) group names and also the new host is being created with a port which already exists in another pool configuration causing FPM to bug out.
Submitted by JamieCameron on Sun, 01/10/2021 - 23:20 Comment #8
So after upgrading, is the file under pool.d created with the wrong group name immediately? Or only after you rename the domain?
Submitted by lexo_ch on Thu, 06/03/2021 - 02:16 Pro Licensee Comment #9
I did not find time to take care of this for a longer time. I just fixed it when it broke manually on the console. But since the last update the error has not occured anymore. It seems to me that this has been fixed. We run the following version: Debian Linux 10 (4.9.0-0.bpo.9-amd64 #1 SMP Debian 4.9.168-1+deb9u5~deb8u1) Webmin: 1.974 Virtualmin: 6.16 Pro Authentic Theme: 19.75
Submitted by IssueBot on Thu, 06/17/2021 - 02:13 Comment #10
Automatically closed - issue fixed for 2 weeks with no activity.