Discovered subtle memory eater after a significant update

(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 processes (currently 1273 and counting :wink: )
  • 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)


  • 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 :wink:
Operating system Debian Linux 11
Webmin version 2.013
Usermin version 1.861
Virtualmin version 7.5
1 Like


Personally, if you have the skill and experience, I’d just remove FCGId support as PHP-FPM is the way to go for any modern system.

In fact, IMHO PHP-FPM is the only execution mode required for a modern system.

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.

Could, but much easier to just frob the php info in the GUI ;)… now that I know it is needed.


I was referring to a bulk update, assuming all sites will support the new version.

1 Like

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…:slight_smile:

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. :cowboy_hat_face:

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.

??? Why bother? This post explained the issue. Everything has been 100% fine for several days.

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.

@MrPete, thanks for posting about this. It’s always great to see posts like this because on the off chance someone else has the problem and follows my patent pending “GTS” (Goog That S**t [1]) troubleshooting method, they should discover related posts like yours.

I also appreciate that you even updated the original post with the updated information about what was causing it and what alleviates or fixes the issue. All too often, as I’m sure you know, forum posts that are a troubleshooting assistance or similar end with the OP just disappearing after several replies are made by others. This means, of course, that people researching answers who come across those posts as described will never know if any of the advice was the answer needed to satisfy the needs of the question, which ones didn’t, which were catastrophic failures, etc.

That’s all. Just wanted to commend you for being part of the solution in a way that benefits everybody, instead of being part of the problem. :salute: o7

[1] The GTS method technically does not intend to suggest or require a specific search engine, hence using “Goog” in the name after my initial realization that there are some people who use shudder yahoo, microsoft/bing, ask jeeves, etc. Luckily, I caught it before the sending the application, which would probably result in the patent office turning me down. :laughing:

1 Like

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