procmail.cache.pag is really huge

We have a really strange issue with that file. i checked it in the forum but no solution found there. So that file is really huge, but not fill up the harddisk

/var/webmin# ls -al|grep procmail.cache.pag -rwx------ 1 root bin 8935744020689978368 2010-04-06 10:53 procmail.cache.pag

/var/webmin# ls -alh|grep procmail.cache.pag -rwx------ 1 root bin 7.8E 2010-04-06 10:53 procmail.cache.pag

it's nearly 8 Exabyte data - hehe - so something wrong here :) so what can we do with that? the most intresting part of it the partiton size is 30 Gb only.

please provide a solution for us before something critical will be happen

thanks Lawrence

Status: 
Active

Comments

The file isn't as large as it looks... if you run this command, you can get an accurate size:

du -hs /var/webmin/procmail.cache*

Virtualmin uses this file to store parsed email logs for faster searching. If you want to remove it, you can... but it will be re-generated when you try to search mail logs via Virtualmin.

~# du -hs /var/webmin/procmail.cache* 19M /var/webmin/procmail.cache.dir 5.2G /var/webmin/procmail.cache.pa

it looks like much better :)

No need to remove it, we just afraid about this file fill up our disk if something uncommon happen (like distribution upgrade to 10.04 LTS) and stop the whole server, but if it's ok then ok. any idea why it show that extreme size?

thanks a lot the replay! it's absolutely ok then.

Automatically closed -- issue fixed for 2 weeks with no activity.

I have found an issue where this did have an effect.

./var/webmin/.procmail.cache.pag.EY1sSi: 70G

Moving a SolusVM VPS from one network node to another network node, the large file size was recorded and transferred, which caused the VPS account to be over quota, and the VPS migration to fail repeatedly.

This cause over a week of downtime while the hosting provider tried to figure out the issue. I think they finally did a manual quota override and performed the migration, but the server was over quota when it came back online, and we had to find large files and delete this cache to get the space back.

I will also note that it took about 10 minutes to delete the transferred cache file, during which time the VPS' server load was 10+!!!

That seems like a bug in the migration process - if a sparse file like procmail.cache.pag is being copied with the cp command, it will be no longer sparse and so consume a huge amount of disk space. If it is copied using tar (which is what Cloudmin does), the original smaller size will be preserved.