ClamWin files in Scratch not deleting

Discussions on webmail and the Professional version.
MailEnable-Ben
Posts: 5858
Joined: Fri Jan 16, 2004 6:49 am
Location: Melbourne

Post by MailEnable-Ben » Mon Nov 15, 2004 11:54 pm

As mentioned in this thread;

http://forum.mailenable.com/viewtopic.p ... 0&start=45

The best thing in this situation is to run the ClamAV whether it be the WIN version or AV version in one thread and see if you have the same issues which from our experiences will not be the case, there have been other AV command line scanners that do not handle running multiple occurances. Namely Symantec and AVG, once reduced to 1 thread any previous reported issues were eliminated.

Possibly the issue here is not what is locking the directories which I would suggest is CLam, due to the MTA not at any stage locking the dir/files. All ME does is copy the dir/files out and then run a command line scanner over them and then delete the files. The reason possibly for the restart of the MTA allowing the deletion of the files is the restart will also dis engage any Clam processes.

Here is what I found in testing;

Ran through 100 messages infected as follows;
25x So Big
25x Bugbear
25x Netsky
25x Elene

With the threads set to 64 the scanner while processing reported the follwoing errors;
LibClamAV Error: cli_cvdload(): Can't create temporary directory C:\Program Files\Mail Enable\Scratch/clamav-1c6d734981cee9c4
LibClamAV Error: Malformed database file C:\clamav-devel\share\clamav/daily.cvd
LibClamAV Error: cli_cvdload(): Can't create temporary directory C:\Program Files\Mail Enable\Scratch/clamav-e04397122e3c891d
LibClamAV Error: Malformed database file C:\clamav-devel\share\clamav/daily.cvd
ERROR: Unable to create temporary directory
ERROR: Unable to create temporary directory
Returned 50

After these 100 messages were sent through twice I had 4 left over directories that could not be deleted, I put this down to the above thwo errors. There was also some left over clam.exe processes which I did not have before runnning this test.

I then reduced the threads to 1 and retested with same messages with no issue, from there I slowely increased the trhead count and managed to get to 34 before the above issue returned. Showing that load in relation to threads seemed to be creating this problem.

So I guess from this recap I would like to hear if anyone had then same issue or any others while running one thread obviously the wider the test scope the better it will be for us all.
Regards,

Product Services
MailEnable Pty Ltd

To keep track of all ME company updates and version releases you should subscribe to the MailEnable list at http://www.mailenable.com or the RSS feed http://www.mailenable.com/rss.

MartynK
Posts: 1364
Joined: Sat Dec 28, 2002 1:12 am
Location: Hong Kong

Post by MartynK » Tue Nov 16, 2004 2:16 am

Ben,

I have read and understand what your saying in your last post, but just to be clear. I don't have any of these errors reported in any log files and all of my emails where delivered OK.

All I found (for the first time ever) is these dir's in the scracth folder that I could do nothing with. It was only after restarting the MTA (because of a config change) that I was suddenly able to delete the dir's. It was as if the MTA had a handle to the folders, but I cannot see why.

If it happens again I will let you know. I am running the latest version of ClamWin (I know you said use ClamAV, but it has not failed me yet) and I have also after your post, set the maximum threads to 32.

Thanks

Martyn

paarlberg
Posts: 1071
Joined: Tue Mar 02, 2004 7:33 pm
Location: Atlanta, GA, USA

Post by paarlberg » Tue Nov 16, 2004 7:07 am

I have reduced my AV engines to f-prot only. The max threads are set to 32.

I am still seeing remnants in the scratch folder. Based on Monday alone, there are just over 300 items in there. Below are the e-mail totals for Monday. Not a very busy day..

Day Mails Size
15 Nov 2004 1335 154.20 MB

This rules out Clam as being the cause.

Guest

Post by Guest » Tue Nov 16, 2004 7:16 am

OK are you running any other pickup events, as this seems strange I have extensively tested F-Prot and never had this occur even running with 64 threads. For futher information we have some of our major sites running 20,000 sites and turning over 250, 000 - 500,000 messages per day with no issues, certainly no reported left over remnants.

Are you running more than this maybe your load is greater? But my inital thoughts on this would be something external or environmental causing this.

MartynK
Posts: 1364
Joined: Sat Dec 28, 2002 1:12 am
Location: Hong Kong

Post by MartynK » Tue Nov 16, 2004 7:18 am

Yes, I must agree that it could be "environmental ", blame it on the ozone layer having a hole !!!

MailEnable-Ben
Posts: 5858
Joined: Fri Jan 16, 2004 6:49 am
Location: Melbourne

Post by MailEnable-Ben » Tue Nov 16, 2004 7:27 am

Sorry that was me I forgot to login for the last post.
Regards,

Product Services
MailEnable Pty Ltd

To keep track of all ME company updates and version releases you should subscribe to the MailEnable list at http://www.mailenable.com or the RSS feed http://www.mailenable.com/rss.

paarlberg
Posts: 1071
Joined: Tue Mar 02, 2004 7:33 pm
Location: Atlanta, GA, USA

Post by paarlberg » Tue Nov 16, 2004 8:17 am

I am running MEFilter as well. A portion of the folders have the MEFxxxxx.mai name structure. I can't turn off MEFilter as it would expose my users to tons of SPAM and unsafe attachments.

I have also noticed that the QUEUE\SMTP\INBOUND\MESSAGES folder also has remnants. I have performed virus scans to see if they were infected files that were not deleted or if they were just remnants.

The virus ratio is only about 5% of these files.

MartynK
Posts: 1364
Joined: Sat Dec 28, 2002 1:12 am
Location: Hong Kong

Post by MartynK » Tue Nov 16, 2004 8:50 am

All the MEFxxxx.MAI files are, are emails that have come in addresses to multiple recipients. These have been split down into a single email per recipient and places into the POP queue for processing just like any other email.

MEFilter just prefixes the original emails filename with the value MEFxxxx where the xxxx is a number starting at 1 (I think) and is incremented for each recipient of the email.

MailEnable
Site Admin
Posts: 4441
Joined: Tue Jun 25, 2002 3:03 am
Location: Melbourne, Victoria Australia

Post by MailEnable » Tue Nov 16, 2004 9:02 am

With the clam tests run, all leftover files/directories were prefixed with CLAM. MailEnable does not create these files, so they must be created by something else (given the filename, clam is the obvious suggestion). The source code for CLAM is public, so we may review and in turn establish why these files remain.

The MTA will unpack the message into a directory structure under the scratch directory, then it will run the a/v scanner, then it cleans the directory. Forseeably, the only way files can get left in this directory is if the scanner does not terminate, holds files open.

Ideally we would like to establish the cause of the issue and get it fixed. We have load tested CLAM and have found some concurrency issues as noted - but these are under excessive load - and seem to be related to temporary files created by clam that have strange ACLs on the files - something that we would like to understand more about.

The reason for looking at CLAM and pickup events in relation to the issue is simply because we are unable to validate the cause of any contention issue. We do know that when the MTA pickup event is run without them issues do not occur.

We have performed extensive testing may be done on running pickup events in general, but it is quite difficult to either comment on or assert the integrity of such without having run tests with the precise configurations (something that is hard to without knowing exactly what the MTA pickup event or scanner is doing).

I have passed on a suggestion to allow more logging in the creation and termination of A/V and MTA pickup event processes to facilitate measuring their performance and integrity.
Regards, Andrew

Post Reply