[clamav-users] Continuous increase of startup time (is daily.cld broken?)
clamav at jubileegroup.co.uk
Fri Oct 18 06:12:40 EDT 2019
On Fri, 18 Oct 2019, Vladislav Kurz via clamav-users wrote:
> On 17/10/2019 17:44, G.W. Haywood via clamav-users wrote:
>> There other ways of dealing with this, as I'm sure you're aware, but
>> using the patched daemon you only have to worry about the increased
>> memory consumption during databse reloads.
> Well, the only option other than using your patch I know of is to
> increase the AV scan timeout in SMTP server. But I'm afraid that the
> sender might give up waiting for the final acknowlegement of DATA. ...
In my experience the only senders who give up early are the spammers,
and rather than at the SMTP 'DATA' stage it's usually at a fairly long
greetpause (I don't want to say how long that is in public). You will
probably not be surprised that I don't care about the spammers.
Here are some of the default Sendmail timeouts as distributed with the
latest Sendmail sources. I'm sure *many* installations are using them:
$ grep -C2 confTO_DATA sendmail-18.104.22.168/cf/README
confTO_RCPT Timeout.rcpt [1h] The timeout waiting for a response
to the RCPT command.
[5m] The timeout waiting for a 354
response from the DATA command.
[1h] The timeout waiting for a block
during DATA phase.
[1h] The timeout waiting for a response
to the final "." that terminates a
As you can see, at one hour, the data 'block' and 'final' timeouts
(where any scan will take place) are well in excess of likely database
reload times, so I do not think you have to worry about extending your
timeouts a few minutes longer. Don't forget that electronic mail came
out in the 1970s (I was there at the time:() and it largely replaced
putting a piece of paper in an envelope and licking a stamp. Way back
then, timeouts of around an hour for mail delivery seemed fairly short
to us, and to me they still seem quite reasonable now. Remember that
email is not (and never was supposed to be) Instant Messaging. Don't
forget that very often on a Linux box, the default connection timeout
for the TCP ESTABLISHED state is five days.
You could also run more than one clamd, and reload them on different
schedules; you could just refuse mail connections while reloading; or
(similarly) you could schedule out-of-service periods for SMTP, only
reloading during those out-of-service periods.
As I've maintained for some considerable time, this reload time issue
isn't really a big deal, and in any case it's manageable. Far more
pressing in my opinion are the issues of coverage and accuracy.
> ... I do not want to accept the message before it is scanned (to
> avoid backscatter or silent discard of messages).
Sure, backscatter is a plague.
More information about the clamav-users