(AFAIK, the following would NOT be an issue after any clean install.)
I just did an update. A painful side effect: over time, the server eats up any amount of RAM I throw at it, in a matter of hours. I just finished diagnosing the problem.
My questions:
Is there a correct way to do post-update Virtualmin “system cleanup” to take care of these things?
I don’t see any instruction for other updates that includes anything that would fix what I’m seeing here. At least it isn’t obvious.
What actually is causing the problem in my case: (@Joe may want to note…)
This update happened to include a move from php 7.3 to php 7.4
Buried in /lib/systemd/system/php-fcgi-<server.dom.ain>.service is a reference to /bin/php-cgi7.3, which no longer exists. As a result, I’ve got a growing pile of non-exited php-loop.pl processes (currently 1273 and counting )
the error is recorded in /home/<server>/logs/php.log but the process never exits.
My guess:
As soon as I go into the Virtualmin gui (server configuration → php options) and re-save the new settings, I assume that file will get auto-updated. It just doesn’t happen during a system update.
(yes, i will switch to FPM but that’s immaterial I suspect, as far as this update issue goes?)
Thoughts? (I will do this as soon as I create this message. Am tired of system crashing LOL)
UPDATE:
Re-saving in the GUI does nothing, as I had not changed anything
Switch to FPM fixes it. Even switching to FPM and back to FCGI fixes it.
So my specific case is resolved. But people may need instruction on this, unless I’ve missed some kind of “after every update, run XYZZY” instruction
I agree, as I noted.
However, the same issue may apply to an upgrade involving PHP-FPM. The only question is, do all appropriate scripts and config files get auto-updated on a PHP version change?
No, but let’s say you upgrade from 8.1 to 8.2 or rather install it alongside…
You could write a script that does the adjustment via the CLI… (Virtualmin API)
Not changing the version automatically is a good thing, as there are breaking changes so code that used to work might stop. So it’s a good idea to audit scripts before committing to an upgrade to the site.
Ram usage in terms of high usage is normal(depending on how much ram you have). if you are not using swap things are fine. I am an outlier as i have 64 gigs of ram in my server so i actually have sql and apache and hp set to use as much as they can without forcing the machine into swapp9ing. It makes things go really fast without having to use exotic caching plugins are other tweaks…
Thanks to a very nice friend, I’ve got a pair of 64GB RAM, 16 core xenon VM host servers. Yeah, I was able to toss a pile of RAM at this. Didn’t make any difference. When memory is being eaten… it’s being eaten.
at this point i would use the virt backup feature and backup the install…wipe the machine and reload with the newest version of the os(that virt supports) you want to use. I am not seeing any memory leaks with virt in any of my servers so probably the upgrade you did has corruption that’s the issue.
By the way, in this case the “script” involved is part of Virtualmin core code, and involves a hidden reference to a specific PHP version. That’s why I linked to @Joe. I assume this will be fixed before long.
)
