Thanks for the suggestions. 1. Of course I can update less frequently, but the problem stays, it'll only occur less frequent 2. I noticed that setting the update to one hour, in fact starts every time about 5 minutes later, it shifts so to speak 3. Interesting idea, but on my system I think it would introduce other problems because each clamav process has to have its own database loaded and that consumes ram, which already is relatively sparse. Beside that you have to take care that the updates of these two processes keep being out of sync. 4. I know, but I had no better way to " solve" it, not for nothing I did ask this question 5. I'll take a look at that
Wouter On 07/08/2015 10:34 AM, Ian Eiloart wrote: > 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 <am...@private-lotus.org> >> 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. > > > > --- e-mail sent by Private Lotus using Exim --- ------------ virus scan by ClamAV ------------- _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
