Weird CloudAV issue with 768mb ram

9 posts / 0 new
Last post
#1 Thu, 12/04/2014 - 02:22

Weird CloudAV issue with 768mb ram

Hi all,

I recently decided to try out a new VPS service Vultr instead of Digitalocean since it comes with 768mb instead of 512mb of RAM. I installed Ubuntu 14.04 on it and then installed Virtualmin immediately.

However, whenever I recheck my server config, I get this error:

ERROR: Can't write to temporary directory
----------- SCAN SUMMARY -----------
Known viruses: 3700716
Engine version: 0.98.5
Scanned directories: 0
Scanned files: 0
Infected files: 0
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 5.059 sec (0 m 5 s)

I did some Googling and it seems that memory is the culprit. However, I have already disabled server side scanning, and I have checked my memory and I have at least 400MB of free RAM.

This is strange because I had no such error back with DigitalOcean even though my VPS there only has 512MB of RAM.

What could be wrong here? I have tried reinstalling on three different instances in different locations under Vultr, but all gave me the same error.

Thu, 12/04/2014 - 02:31
Joe's picture

Are you able to write files to /tmp successfully?

How about as the clam user? (That's the clamscan program that's having problems.)

You can do that with:

su -c 'touch /tmp/test' - clamav

(Note that "clamav" needs to be whatever the clam user is named on your system, which will depend on your OS.)


Check out the forum guidelines!

Thu, 12/04/2014 - 04:04

I'm using Ubuntu so would that be the correct command? I tried entering it and I didn't get any error message shown. How do I know if I executed the command correctly?

Thu, 12/04/2014 - 09:28


You can determine if the command ran correctly by looking in the "/tmp" directory, and seeing if there is a file named "test" that's owned by the clamav user.


Thu, 12/04/2014 - 11:52

Nope, there isn't such a file created. Anyway, I created a swapfile and ClamAV appears to run properly now. Even then, the su -c 'touch /tmp/test' - clamav command still has no effect.

I am still curious as to why ClamAV fails with 768MB of RAM but works with 512MB of RAM. Does Virtualmin have some RAM-related settings causing some modules to consume more memory? I have set up both my 512MB VPS and 768MB VPS with the exact same settings, but the former consumes only about 290MB whereas about 500MB+ is already used up on the latter.

Thank you!

Thu, 12/04/2014 - 12:05

Virtualmin doesn't handle things differently based on the amount of available memory.

You may indeed be seeing memory related issues though.

If your system with 512MB of RAM is 32 bit, but the 768MB system is 64 bit -- your amount of available RAM would actually be less in the second case.

Alternatively, since RAM is a bit low -- you could always configure ClamAV to use the command line scanner, and not run the ClamAV daemon. That can be configured in Email Messages -> Spam and Virus Scanning.


Thu, 12/04/2014 - 13:27 (Reply to #6)
Joe's picture

"Virtualmin doesn't handle things differently based on the amount of available memory."

That's not entirely true.

During the initial configuration "wizard" step, Virtualmin will check memory, and make a few decisions for you based on the available memory. But, 512M and 768M aren't going to get different configurations at that stage, I don't think.

It would be possible for Virtualmin to end up using more memory based on decisions the administrator makes at that stage, though. The biggest potential memory users are clamd, spamd, running both databases (MySQL and PostgreSQL) rather than just one. I believe the MySQL configuration gets adjusted at this stage, too (choosing the buffers and such).

But, it shouldn't be a large difference.


Check out the forum guidelines!

Thu, 12/04/2014 - 12:16

Thanks for the suggestions. I thought setting the MySQL database optimisations would help with the RAM management.

Both installations are 64-bit.

Anyway, it just seems pretty strange. I did another re-imaging and this time using 'free -m' shows 400MB of free RAM. Yet, I'm still getting the same error with CloudAV.

Sat, 12/06/2014 - 13:07

I did some more troubleshooting and I still don't know what's wrong.

Free -m reports 400mb of free RAM on my 768mb vps but only 150mb on the 512mb vps. Both run Ubuntu 14.04 x64 and have no swap configured (both are kvm servers). Yet, the first fails whereas the second one succeeds.

Yet, I am able to run clamscan from the command line successfully, and on the 768mb system, I'm still able to access Virtualmin as per normal during the scan, but on the 512mb system if I try to access Virtualmin during the scan, the clamscan process is killed. So that is consistent with the fact that my 768mb has more memory.

Adding swap or switching to x86 on the former system seems to solve the problem, but it's still puzzling why one works and the other doesn't. I was wondering if there is a bug within Virtualmin on odd-sized systems when running clamscan since clamscan works perfectly fine from the command line.

BTW, I realised I need exactly 256MB of additional swap for the error to stop appearing. Yet, when I kept spamming 'free -m' in the console while the server check was running, only 8MB of the swapfile was being used... so clearly I have enough memory but somehow something in Virtualmin/clamscan thinks I have insufficient memory.

Topic locked