Virtualmin php-fpm rewriting group after switch

Unfortunately, I can’t respond to the forum here so I had to open up a new topic.

and
Wrong group id in PHP-FPM - #4 (Jan 2017)
and
Webmin Update Causes php-fpm failure - #18 by Ilia (Januar 2020)

@Joe

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.

Steps.

  1. Import a server into a new virtualmin installation where the actual server is a subserver.

  2. 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.

  3. You create the server or you import the group virtualmin server

  4. now you can import the virtualmin sub server with the domain

  5. Now you migrate the virtualmin sub-server to be a main (parent) server and you change the username

  6. 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!

  7. You correct the group-name to match the user-name - both group and username actually are already existing on the server as they had been correctly created by virtualmin.
    Screen Shot 2020-09-10 at 08.10.15

  8. You do a power recycle and the server is running again and the php-fpm line shows up again.
    Screen Shot 2020-09-10 at 08.20.43

  9. You switch back to fcgi

  10. The error message will pop up that the php-fpm server is no more running and all php pages get a 503

  11. again you switch back to php-fpm

  12. you do what has been described above already and correct the group name to match the user name in etc/php/7.4/fpm/pool.e/try to find the pool for that user - not easy as there are only numbers!!

  13. reboot - the server won’t reboot (probably related to another problem with netplan) -


    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

Screen Shot 2020-09-10 at 08.59.07

in www is written
Screen Shot 2020-09-10 at 09.01.01


and here the screenshot from the group and ugroup - ONLY the ugroup is wrong!
Screen Shot 2020-09-10 at 09.20.16

OK, I guess it does happen occasionally. :wink:

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.

1 Like

Ah, I see. Y’all gotta keep it brief! I don’t have a lot of free time for the forums (or for anything). I just saw a huge wall of text and tried to skim some meaning out of it.

But, yeah, you’re right. That’s a bug-like. I’ll file a bug for Jamie.

Edit: Ticket is here.

1 Like

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