Re: [exim] [clamav-users] problem reading socket while updat…

Top Page
Delete this message
Reply to this message
Author: Ian Eiloart
Date:  
To: ClamAV users ML
CC: Exim Users
Subject: Re: [exim] [clamav-users] problem reading socket while updating database
Apologies for cross posting. This question is about Exim and clamd. Specifically, how can we deal with a clam daemon that’s unresponsive (for five minutes) while updating rules. The obvious thing would be to wait a bit longer rather than time out, but I can’t see a control for that. I have some alternative suggestions, of which (3) below seems most promising, if somewhat complicated.


> On 30 Jun 2015, at 07:38, Jingo Administrator <amigo@???> wrote:
>
> The problem I have with this is that, when during the update exim4 sends a
> message to the daemon to be checked by clamav, I get an error message in
> /var/log/exim4/paniclog stating :
> 2015-06-19 13:51:10 [21601] 1Z5unF-0005cP-Lg malware acl condition:
> clamd: unable to read from socket (Connection timed out)


My guess is that, if you check the main log, you’ll see the message has been deferred. That should mean that it will be delivered at the next attempt: unless rules are updating again.

Simple things you can do in mitigation:
1. Update rules less frequently. If you do it hourly, you may find senders retrying hourly and being repeatedly deferred. Perhaps only update every three hours.

2. Update at more unusual frequencies. Perhaps every 65 minutes rather than 60, for example. This will reduce the chance that a message will be deferred more than once.

3. Have Clamd running two processes, each listening on a virtual interface, and updating at different times. Then say something like "av_scanner = clamd:192.0.2.3 1234:local : 192.0.2.4 1234:local". I’ve not tried this, but don’t see why it shouldn’t work. You may be able to use different ports on the same IP address. You can’t do this with UNIX sockets. If it does work, Exim will balance the load between the Clam processes, and will try the other process if a timeout occurs. You’ll want to limit CPU usage for each Clam process, to perhaps 25%, or something. I don’t know if it’s possible for Clam to refuse connections while updating (rather than timeout), but that would be preferable.

4. use /defer_ok (simple, gets your email accepted quickly, reduces security) to accept email when ClamAV is not available. Probably not such a good idea.

5. set smtp_receive_timeout to 10m. The default is 5m, and this may be what is causing the scan to time out. I don’t know if that’s the case, but I can’t find any explicit controls in Exim’s docs.




--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148