| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Debian Linux 12 |
| Virtualmin version | 7.30.4 |
This the running process on my Linux server 10mn after a restart.
On and on, webmin is using a lot of memory with no mail and only one website.
I have 2 other Virtualmin installed and there the running process are completely different.
Any ideas on how to reduce memory consumption ?
Something pathological is happening, but I can’t guess what. Those collectinfo.pl processes are huge, they should only run for a few seconds, and it shouldn’t run if another one is already running. Are you out of disk space on any of your partitions?
collectinfo.pl does start apt-get, though, and apt-get can grow pretty large in some circumstances. So, check to be sure apt-get update is behaving, and maybe make sure nothing is weird about the state of your packages (e.g. dpkg --configure -a and check for errors/issues). I can’t think of anything else collectinfo.pl would be doing that’d take a long time or consume a lot of memory.
Oh, and, try this:
Grab the PID of one of those collectinfo.pl processes, any one will do as long as it’s running.
Then do:
strace -p <pid-of-process>
And, see what it’s doing. Maybe show us a couple dozen lines of whatever it’s doing, if it’s not obvious to you what it’s doing. That shows syscalls as they happen, so it may or may not show us something interesting about what kind of work collectinfo is trying to do. It may be “hung” waiting for something (e.g. if apt-get update is really slow or some other query it’s trying to do is timing out).
Thank you Joe for looking at this.
Some feedback;
I restarted the Server (a virtual container) 24h ago and I have only one collection.pl running (207422 root 2.12 GiB /usr/share/webmin/virtual-server/collectinfo.pl). (to be confirmed with monitoring in time). It is the same PID for 3 to 5mn start around 76Mb and ends around 2.9Gb. Then after a minute or two a new one start and so on.
This instance has a lot of free disk space (110.33 GiB used / 133.26 GiB free / 243.59 GiB total)
apt-get update, apt-get upgrade and dpkg --configure -a behave normally (0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded and no errors)
I ran strace -p <pid-of-process> and I have A tons of
newfstatat(AT_FDCWD, "/home/domain/tmp/sess_otn0ga3qgsblrs54ktu2n2l36h", {st_mode=S_IFREG|0600, st_size=349, ...}, 0) = 0.
For more rows: pastebin.
At some point, I guess after reaching 2.92Gb the last row:
newfstatat(AT_FDCWD, "/home/aimfair/tmp/sess_8s5rqqvarm9066bej0uhe7n7e8", {st_mode=S_IFREG|0600, st_size=651, ...}, 0) = 0 +++ killed by SIGKILL +++
Edit; I have now 4 collectinfo.pl running:
|226486|root|1.55 GiB|/usr/share/webmin/virtual-server/collectinfo.pl| |227651|root|1.52 GiB|/usr/share/webmin/virtual-server/collectinfo.pl| |228802|root|1.49 GiB|/usr/share/webmin/virtual-server/collectinfo.pl| |229817|root|1.48 GiB|/usr/share/webmin/virtual-server/collectinfo.pl|
Hope that help pointing the issue.
Bernard
Thank you Stefan for pointing to this configuration panel. 
So, those are session files, presumably for a web app you have running on your system, maybe something PHP, maybe something else. Having a gazillion of them is probably indicative of something going wrong. Normally web apps clean up after themselves, and most folks running a single shared hosting system don’t run apps that have hundreds of thousands of daily logged in users for their apps.
Why Virtualmin is reading them is a mystery to me, though. I’ll have to look at the code.
Are you using soft disk quotas, by any chance? I think in that case, we’d check usage simply by looking at the files and adding the sizes up, and a gazillion files would take a while to think about.
I just check, I usually have quota set to unlimited on my different server, but on this one I don’t see this section when I Edit the Virtual Server.
On the Edit Server Template, Default Settings the Disk quotas type is set to Hard (enforced)
Something to change for better management ?
I understand something is creating gazillion of “sess_”.
I will need a way to track this, but for now I can’t even see the directory content.
I went to the tmp folder and ran “ls -l” 5mn ago and still no output. 
I believe I should first empty this directory to be able to get back to a “semi-normal” state.
Then check what is creating so much files.
But I fear a simple
rm sess_* won’t work.
A failsafe system will be good, but first I need to find what is producing so many files and why they aren’t flushed.
Thanks.
@Jamie, cleanup_php_sessions should process those files in batches, rather than reading all of them into @rv (into memory) in one shot.
No, hard quotas are handled by the kernel, and have almost no performance impact.
Try applying this patch to see if the original issue is resolved, and if the PHP session files are cleared correctly:
webmin patch https://github.com/virtualmin/virtualmin-gpl/commit/9e844a7
Yeah, because it’s just too many files in the directory!
When you type rm sess_*, the shell expands the * wildcard into a full list of matching filenames, which then gets passed as arguments to rm command. But the problem is that OS impose a limit on the total size of arguments and environment variables.
The patch I linked in my previous comment should resolve both the OOM issue and the file deletion issue.
In this case, if you don’t use Virtualmin, it’s much simpler to remove the directory and recreate it. The following should work when logged in as the domain owner:
mkdir -p ~/tmp_new
chmod --reference=~/tmp ~/tmp_new
find ~/tmp -name "sess_*" -mtime -7 -exec cp -p {} ~/tmp_new/ \; # save recent sessions if needed
rm -rf ~/tmp
mv ~/tmp_new ~/tmp
Thank you Illia,
Here the output:
root@bsfez:~# webmin patch https://github.com/virtualmin/virtualmin-gpl/commit/9e844a7
Patch failed: Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 9e844a75b2947b6265262dd17154e89101c924d6 Mon Sep 17 00:00:00 2001
|From: Ilia Ross <ilia@ross.gdn>
|Date: Mon, 3 Mar 2025 21:36:39 +0200
|Subject: [PATCH] Fix to avoid OOM for directories with too many temp files
|
|https://forum.virtualmin.com/t/webmin-collection-and-others-high-memory-consumption/132362/9?u=ilia
|---
| collectinfo.pl | 2 +-
| php-lib.pl | 29 +++++++++++++++++------------
| 2 files changed, 18 insertions(+), 13 deletions(-)
|
|diff --git a/collectinfo.pl b/collectinfo.pl
|index fc1043042..117a919aa 100755
|--- a/collectinfo.pl
|+++ b/collectinfo.pl
--------------------------
patching file collectinfo.pl
Using Plan A...
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
Hunk #1 ignored at 64.
1 out of 1 hunk ignored -- saving rejects to file collectinfo.pl.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/php-lib.pl b/php-lib.pl
|index 47a4d83f5..edc10cbf5 100755
|--- a/php-lib.pl
|+++ b/php-lib.pl
--------------------------
patching file php-lib.pl
Using Plan A...
Hunk #1 FAILED at 2819.
Hunk #2 FAILED at 2844.
2 out of 2 hunks FAILED -- saving rejects to file php-lib.pl.rej
done
Ah, yes! There were other changes to that function. Then manually edit php-lib.pl, replace the cleanup_php_sessions function with the following, and restart Webmin using systemctl restart webmin when done:
Ok Ilia, after applying this patch and restarted webmin 1h ago, collectinfo.pl stops at 1.06G.
That tells me it’s simply not able to keep up and can’t finish in time for the next one to arrive.
How many session files are there? ls probably won’t work if it’s really a huge number, so you can do something like:
find . -type f | wc -l
To get the number of files in the current directory.
We don’t permit another instance of collectinfo.pl to run:
What is the output of the following command on your system:
grep -Rsi lockmode /etc/webmin
Ah, actually, I see an issue.
@bsfez Apply the following patch and try again:
webmin patch https://github.com/virtualmin/virtualmin-gpl/commit/4a96244
Do you mean it won’t even work with my latest patch? But it should…