chpax -m /usr/bin/clamscan

BTW, if you are using clamd you can also run clamdscan which is MUCH faster.

Okay added another update this morning...

ran...


Then used clamdscan instead of clamscan and it worked fine...

14 minutes complete scan vs 55min + for clamscan...

thanks, it's all good.

Yeah clamdscan is WAY faster.

Hi could someone look at ticket 15099.

I was told - " Ok so it looks like virtuozzo is killing the process / resource starving it. Theres nothing we can do about that other than to disable most of th signatures in it (kind of defeating the purpose!). I&#... "

Yum GUI said their was an update to gradm - I duly yum updated > gradm-2.9-8.el5.art.x86_64 and after postfix being pummelled for the last couple of weeks its now suddenly stopped and I am not getting an avalanche of mail telling me psmon has a problem with clamd.

I thought it fixed the problem but it didn't !

The gradm update stops clamd. Looking at the output of rpm -q --triggers gradm I see some code that stops clamd to run chpax -m on it. Restarting it seems to be left to psmon.

So yes, if you have a resource problem preventing clamd from starting, then yes, psmon will try over and over to start it.

Thats the thing i am running ASL on 3 identical servers so it doesn't quite make sense, so I am puzzled

Identical in hardware, but probably not in memory usage at every point in time.

As I understand the case, apparently virtuozzo is killing of clamd because its using more memory that the VPS will allow.



Are they all configured identically, and for these 3 servers are they all VPS'? As I understand it the one we looked at was a VPS, are these others as well? And what are the memory limits on these VPS'?

Hi Mike,

sorry i never saw this post.

Its a Plesk Linux 2GB VPS with 4GB Burstable RAM with a few sites on the box.

I have ASL running on two other vps with the same spec with no repeated psmon emails.

i dont believe the VPS is under specced and I wouldn't have thought ClamAV uses a huge amount of memory, certainly not bursting up to 4GB - the same specced up setup has run ASL without a problem which is puzzling.

I uninstalled and reinstalled to no avail so am not sure if shrapnel left behind confused matters but I thought the uninstall would clean out all previous parameters.

ClamAV can use quite a lot of memory, so I'm afraid your problem is in fact being underspecced. Burstable RAM sounds fancy, but I believe that just means you can use it when it's available (i.e. not already in use by other users on the same hardware), so at busy times your server will only have 2 GB of RAM, which frankly isn't that much.

Plus total memory isnt the only limitation in openvz, there are also process level limits that can starve a process or user of other resources.

One way to reduce clamd's memory footprint is to disable safebrowsing at the end of /etc/freshclam.conf (and /var/asl/data/templates/template-freshclam.conf (and you need to check thetemplate regularly)

I can't remember if there's an option in /etc/asl/config or not to disable this permanently. safebrowsing is a serious memory hog and we don't use it on all our systems for that reason.

The RHEL6-based OpenVZ kernels support VSwap, which supersedes user beancounters and makes the whole resource limit thing a lot simpler: http://wiki.openvz.org/VSwap This is a pretty new feature though, so maybe not many OpenVZ hosters are using this yet.

Hi Breun I thought the above was completely over my head but I read it through and it makes sense.

I know its not applicable to me as its not implemented and I am on Cent5 but its an interesting read nonetheless.

i will try and see if faris's options alleviate the problems.

I understand that disabling safebrowsing may reduce memory consumption but what type of security hit would i possibly take ?

It doesn't really matter what OS the virtual server is running, this is about the kernel running on the host node. VSwap is implemented in the RHEL6-based OpenVZ kernel and needs to be configured on the host node. I assume you are not controlling the OpenVZ host node?

Your virtual server is probably using the previous OpenVZ resource limit system, which is user beancounters: http://wiki.openvz.org/UBC This system has a whole lot more limits and can cause programs not to start because some limit has been reached without actually using all available RAM, which is what Scott was referring to.