Hello Gordon, On Fri, Feb 18, 2011 at 10:07:31AM -0500, Gordon Dickens wrote:
That is quite strange especially since it only occurs sometimes. I can't say for sure but I suspect that this is most probably a ClamAV problem. Check to see if the clamd logs have any related entries that might yield a clue. I checked the clamav.log and when the error occurs I find lines like:
Tue Feb 15 22:20:42 2011 -> /var/spool/exim4/scan/XXXX/XXXX.eml: Can't create temporary directory ERROR Just like in exim's paniclog.
I realize this is obvious but make sure that the Debian-exim user and clamav user both have read/write permission to the /var/spool/exim4/scan directory. In fact the permissions to this directory are as follows:
ls -l /var/spool/exim4/ | grep scan drwxr-x--- 2 Debian-exim Debian-exim 4096 Feb 18 12:54 scan Before I checked this, but somehow was not noting the missing w for the group. So the Debian-exim group has NO write-permission. On another system running exim4u (which I use as the primary MX) the permissions are identical and I do not have any errors of this kind there. Probably here lies the problem. But since I do not have any problems on the other system, I would like to understand first, why I really need write access here. How does virus scanning actually works? Which process really needs access to this directory? Then I would like to understand why there are no problems on my other system.
It sounds like everything is running fine until some unusual convergence of events occur. I would also examine your clamd configuration file (/etc/clamd.conf). There are several parameters in clamd.conf that specify maximum allowable values such as MaxConnectionQueueLength, StreamMaxLength and MaxThreads.
This mailing list post is for a similar situation:
http://lists.exim.org/lurker/message/20050414.060700.734834f7.en.html
The above link suggested that the user uncoment or add in the clamd.conf file: AllowSupplementaryGroups As far as I understand for this to take effect, one must run clamd as root.
I also found this post for the exact same situation as you have encountered:
http://www.directadmin.com/forum/showthread.php?t=30992
However, it did not offer a solution except for the following: "Changed some exim and clamd settings and voila my problem seems solved!" Yeah, not really helpful.
I checked the logs on my servers and have not yet seen this error message, however, I will continue to watch my logs closely especially for my relay domains. Thank you!
Best, Udo