2010/4/8 Török Edwin <edwinto...@gmail.com>: >> I do have strace. I am having trouble recreating the problem. I first >> uploaded the file to the server, but it scanned clean. I then >> configured MIMEDefang to leave its files behind after processing, sent >> myself a PDF that triggered the error, and then manually scan ned the >> left-behind file. This scan succeeded. >> >> I am not sure what failure mode would make this succeed with clamscan >> on the command line but fail when called by MIMEDefang. > > Does MIMEDefang use clamdscan or clamscan?
We are using clamd. MIMEDefang can use both, but prefers clamd if it is available. >> I will also drop back to 0.95.2 to see if the problem was the OS >> upgrade or the clamav upgrade. My MX servers are experiencing the same problem, but I just noticed that they have a higher size threshold - my test 2.5M PDF gets through OK, but a 7M PDF triggers "can't map file into memory" error. I am starting to suspect a resource exhaustion issue. I just restarted clamd on one of the inbound servers and the problem remains, but the threshold increased. Now, 10M files are getting through but a 25M file caused the error. On the upgrade/downgrade test server, not only did the issue go away for 2M files when I downgraded, it remained gone when I upgraded back. This is consistent with the exhaustion theory. The servers that were exhibiting the problem vigorously today are the ones that I upgraded first - days before the other servers. From the logs, the problem has been getting steadily more frequent over time. In another branch of this thread, Chuck Swiger suggested that munmap()s might not be happening, which may be consistent with this theory (in my limited view as a sysadmin; I am not a developer). Edwin, should I proceed with the source modification you suggested earlier, or something else? Royce _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
