Config check status

[danboid]

Its often not clear if and when the vmin System Settings -> Re-Check Configuration page is doing anything.

The main offender in this regard for me is:

"PHP versions have changed to ... since last check. Regenerating any missing php.ini files"

On a server with multiple versions of PHP installed and several hundred users / domains this step seems to take an incredibly long time but there is no indication that anything is actually going on in the backgroud once this process has started so it would be good if the list of domain/user config files were displayed as they are being processed.

I presume that this process stops as soon as I browse to a different vmin option or close the tab running the config check?

[iliajie]

I presume that this process stops as soon as I browse to a different vmin option or close the tab running the config check?

Actually, you're right, it does stop indeed if you leave config-check page! @jcameron Jamie, it can be a problem if we're writing files! We should treat check.cgi the same way we do other important operations, i.e. use obtain_lock_anything with it.

"PHP versions have changed to ... since last check. Regenerating any missing php.ini files"

Don't you have a red progress bar bouncing left and right?

[danboid]

Don't you have a red progress bar bouncing left and right?

No, not under vmin 7.5 Pro and using Firefox 111

[danboid]

My vmin config check tab usually times out because the vmin session expires before all the users php.ini files get updated as it did earlier so I've had to start over by running virtualmin check-config in a tmux session instead.

[jcameron]

I'll take a look and see why this operation is so slow!

[danboid]

Thanks Jamie!

I should've used time yesterday to time how long running a config check took. I logged back in a few hours after it had started updating the php.ini files and it was still at it.

I checked again this morning and it had completed (the php update) but the config check ended with this error:

Updating all Webmin users with new settings..
Error: Failed to lock file /etc/webmin/virtual-server/webminlock after 5 minutes. Last error was : Locked by PID 14850
Error
-----
Failed to lock file /etc/webmin/virtual-server/webminlock after 5 minutes. Last error was : Locked by PID 14850
-----

What might've caused that to happen? Maybe I need to re-run the config check? If so I'll time the next run.

We have about 800 domains/users on this vmin server and it has 32 GB RAM & 8 Xeon cores.

[jcameron]

Ok, that's interesting ... it seems like some other process is holding a lock that's preventing the config re-check from completing.

What does /etc/webmin/virtual-server/webminlock.lock contain? If it's a PID, what process is that?

[danboid]

Ok, that's interesting ... it seems like some other process is holding a lock that's preventing the config re-check from completing.

What does /etc/webmin/virtual-server/webminlock.lock contain? If it's a PID, what process is that?

That file doesn't currently exist on our vmin server. Maybe it did when I was running the config check?

[jcameron]

Yes, that's possible. If you re-run the config check, does it fail in the same way?

[danboid]

I just successfully re-ran check config. It only takes 52s when the php versions haven't changed and there were no errors this time.

We currently have 5 versions of php installed on this server - 3 versions of 7.x and two 8.x but I can reduce that to two - the latest 7.x and 8.x would suffice.

Did you work out why updating the php.ini files takes so long?

[jcameron]

I did find an opportunity to optimize this check recently that should speed it up for the 7.8 Virtualmin release..

[iliajie]

@danboid If you wish to try the patch, it can be found here.

[danboid]

I'm trying the patch now. I removed two old 7.x versions of php before running the config check from the terminal but its still taking a long time.

I'll update this post when its finished to say how long it took but because it still takes a long time it would be useful if the config check printed the current user/domain being updated so that the admin has some idea of how long it might take.

It's especially important because this update process seems to stop most if not all php sites working whilst the ini files are being updated.

[danboid]

It took 204m35.150s to run check config just now. The only error was one user is missing a passwd entry.

I'm not sure as I didn't time the last check config but I think that might actually be faster although it still seems like too long to update ~770 users/domains on a 8 core Xeon with 32 GB RAM.

The good news is that the Updating all Webmin users with new settings.. stage didn't produce errors this time.

[jcameron]

When the config check is running, if you run the top command do you see the check.cgi or check-config command using up a lot of CPU time? That would be useful to know if it's doing something, or just stuck on a lock ..

[danboid]

Could you add some kind of progress output to the check config script so that the admin can see whats going on easier when the php configs are being updated?

Am I right in thinking that all php sites hosted on the vmin server running the check config script become inaccessible or at least partly broken when vmin is updating the php.ini files during a config check run following a PHP version change?

We still have a version of php installed that we could remove so I could remove that soon, check out htop whilst its doing it and time it again. I'll wait until you make it a bit more verbose if you can.

[jcameron]

No, existing sites shouldn't be impacted in any way during the config re-check.

[danboid]

Good to hear it!

[chris001]

204 minutes, sounds like a good place to print to the page the name of each domain it's checking/fixing, as it fixes it, and messages about waiting to obtain locks on files, so the user could see what is taking so long.

[jcameron]

Good idea, I've added a progress check in https://github.com/virtualmin/virtualmin-gpl/commit/26d20651b9c0ab82299764252a873a86849fb71e