Re: [AMaViS-user] virus_scan FAILED .. filling up my disk space

[Jernej P. <jer...@ar...>]

Miha,

On Feb 24, 2010, at 10:37 AM, miha vrhovnik @ domenca wrote:
> "Michael Scheidell" <sch...@se...> wrote on 22.2.2010 16:20:15:
> 
>> On 2/22/10 3:30 AM, miha vrhovnik @ domenca wrote:
>>> 
>>> 
>> you can already tell clamav not to unzip past (x) number of levels, and 
> as zip is uncommented in amavis config file in @decoders section and a large amount (1000)of partX files was in ./parts directory I believe decoding is already done by amavis.

If you are checking the whole email (email.txt) (with $bypass_decode_parts = false), then you get the whole email and the whole parts combined together, so basically you clamav needs to check your emails (body part + attachments) at least twice. (Check the amavisd.conf settings for deep explanation of bypass_decode_parts and other settings).

My recommendation would be to turn off the clamav uncompressing features (ScanArchive no), or tune the limits for uncompressing to be able to scan such emails that your machine could handle (since I believe that your machine is unable to handle the full load of scanning your emails).

>> you can already give it a max archive size.
>> the tmp dir cleanup can be done with a cronjob and find -mtime options.
> How old directories I'm supposed to remove? 1h, half a day? I doubt that this would help much in a case I had. I had 2 legit! messages one just under 20M in size (this is the max server would allow) which had a zip file with 20 or so bmp files zipped in.. uncompressed size was around 120M + message itself 140M. The other was 8M in size with 5,5M zip file which contained 14 zip files with total above 1000 files mostly js, html, gif, css.. also around good 100M of decompressed files. Both of this messages burnt 50G of free space during the night!

If you stop amavisd, the daemon should remove all temporary files that were in use at particular time. For all other directories in $TEMPBASE directory, which are there after stopping amavisd, there is a reason for being there. Usually amavisd retains them for your analysis and you get log line something like "PRESERVING EVIDENCE in ..".

If I remember right, Michael already adviced a rule of a thumb a while ago for $TEMPBASE directory retention policy, which is I believe: you can safely delete $TEMPBASE/dirs which are older that one day, if you are not inspecting them, why there weren't processed sucessfully.

regards, Jernej