It seems to be the elephant in the room, but the root cause of your problem is
you have a resource-constrained system. You don't have enough RAM or CPU to do
what you want. I had the same problem with older Solaris systems running SPARC
processors and no amount of cleverness on my part helped. The problem went away
when I bought multi-core/multi-processor Dell servers with 24G of RAM. Mail
processing is not the only thing my servers do.
Scanning incoming and outgoing mail in real time with little or no interruption
takes computing power, and the runset size with a full complement of signatures
given your memory size will suck up all the RAM that could be used for caching,
and that drives up disk IO and that slows things down considerably. Even with SSD.
Clamd could benefit from using dedicated shared memory but that's not likely
happen, and even if it were available I doubt many would exploit it. It isn't
needed with modern datacenter-class systems which is not what you have.
dp
On 7/8/15 1: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.
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
