This is not a thing that ever happens. Literally, I don’t think I’ve ever seen this problem before, even once. It’s something unique in your deployment, but I don’t know what.
It happens regularly I woudl say as the problem is related to the migration of virtual servers. When you import a virtual server to a new virtualmin installation and the group is EXISTING even than the Group gers switched back to the previous one.
Import a server into a new virtualmin installation where the actual server is a subserver.
if the group is not existing you get prompted to create first that group or to import that group. no matter what way both have same results.
You create the server or you import the group virtualmin server
now you can import the virtualmin sub server with the domain
Now you migrate the virtualmin sub-server to be a main (parent) server and you change the username
All our servers where FCGI but now we like to run PHP-FPM so we switch them to PHP-FPM and the SPM server won’t restart and even worse the line for the php-fpm server is disappearing from the Dashboard and there is no way actually to restart the php-fpm server or getting back that line for the php-fpm server!
but when we do a power recycle the server is up and running again and also the php-fpm-line shows up again.
This should never happen as the virtualmin user has no way to find easily the source for the problem and then an easy way to change the group ID as described in the other posts.
Why does the new groupID which actually get created not also assigned and written to the virtual server settings, when a subserver gets imported to a new virtualmin installation or restored to an old one?
And I just realized that the default settings of php-fpm also not get taken and instatt again “dynamic” instead of the sefault settings which are “ondemand” get taken
in www is written
and here the screenshot from the group and ugroup - ONLY the ugroup is wrong!
I still don’t understand it. Can we focus on one specific issue, and not talk about the other FPM config issues in this topic? I’m having a hard time following and we have barely started.
So…I vaguely recall this conversation (I can’t take enough time to read over it again right now, as I’ve got like three minutes to spare) and I think the issue was that the group was wrong in the Virtualmin configuration. There was a lot of talking around changing it in the PHP/FPM config but I don’t recall if it was ever updated in the right place (in the Virtualmin configuration in /etc/webmin/virtual-server), which is where it needs to happen to make it “stick” through changes to the execution mode etc.
If we can zero in on that (whatever option it is and what it gets set to on restoration), I can file a ticket that Jamie can understand and we can get this fixed in the next release. Don’t bother changing it in the FPM config and then breaking it again by changing execution modes. That’s already established as a problem…we need to figure out what config isn’t getting imported/translated correctly in Virtualmin.
Hi Joe - check out the last screenshot and I really suggest you check all the screenshots as then you see where the actual problem is.
When you import a server no matter from where or restore a server than the USER UGROUP and GROUP need to have the same name - and that should not be so difficult to achieve in case you import a server which was already a main server!
But in case you import a subserver and than MOVE it to be a Main server also here the USER UGROUP and GROUP have to be set to the same names. Nothing more is needed. As it changes already GROUP I really don’t know and can’t find a logic why UGROUP does not get changed too. That is the hickup which is causing those problems. And that is what I woudl fix.
It does not happen occassionally by the way as ALL our imported and restored servers had the same problem and we have many more servers actually to come.
And the problem I mentioned with REBOOT from virtualmin also gets fixed if all UGROUP reflect the same as GROUP then also the reboot command will work fast and reliable - just tested and the php-fpm line will show up too.