[clamav-users] Occasional sendmail queue delay when using clamav-milter

G.W. Haywood clamav at jubileegroup.co.uk
Thu May 3 04:14:51 EDT 2018


Hello again,

On Wed, 2 May 2018, Aaron Paetznick wrote:

> ... both very helpful, thanks! ... sorry for the late reply ...

It's why we're here.  Don't be. :)

> ... small course corrections and long periods of observation.

The correct approach, IMHO.

> Here are my log levels:
>
> define(`confMILTER_LOG_LEVEL', `8')
> define(`confLOG_LEVEL', `10')

For investigation I'd suggest 22 and 15 respectively, but keep an eye
on the logs as that's rather verbose.  And don't tell Claus. :)

> For the record, I'm running a distinct copy of clamd using a local unix
> domain socket on each server. I'd be happy to consider switching to TCP,

I wouldn't suggest that's necessary, nor even desirable.

> ...
> Here's some threaded top output for my clamd process:
> ...
> ?? PID USER????? PR? NI??? VIRT??? RES??? SHR S %CPU %MEM???? TIME+ COMMAND
> ? 1324 clamav??? 20?? 0? 975436 709588?? 3264 S? 0.0? 5.9 3:17.37 clamd
> ? 1678 clamav??? 20?? 0? 975436 709588?? 3264 S? 0.0? 5.9 0:08.38 clamd
> ?57290 clamav??? 20?? 0? 975436 709588?? 3264 S? 0.0? 5.9 1:17.77 clamd
> ?57438 clamav??? 20?? 0? 975436 709588?? 3264 S? 0.0? 5.9 0:56.31 clamd

Interesting.  This is the sort of thing I see here:

670 clamav    20   0 1035580 673556  12344 S  0.0  4.1 199:44.38 clamd
671 clamav    20   0 1035580 673556  12344 S  0.0  4.1   0:00.22 clamd

This clamd instance has been running for nearly six months.  As you
can see there are only two threads and only one of them has done any
real work.  (The reason that it hardly ever does any work is that my
homebrew milter does all the heavy lifting before clamd gets a chance
to see the mail data.)  I typically see more clamav-milter threads.
Maybe this is just characteristic of your heavier loads.  Maybe this
is a threads issue - it's the sort of thing they do - but I'd have
expected to hear more about it on the list if it were something in
need of fixing and I don't want to send you off chasing wild geese.

> Reloading the clamd databases typically takes under 10 seconds.

That's a lot quicker than typical here, which databases are you using?

> I am running two total milters, the other being opendkim. ... 
> INPUT_MAIL_FILTER(`clamav',
> `S=local:/var/run/clamav-milter/clamav-milter.sock, F=T, T=S:4m;R:4m')
> INPUT_MAIL_FILTER(`opendkim', `S=local:/var/run/opendkim/opendkim.sock')

You're using the default (10 second) timeouts for 'S' and 'R' for the
opendkim milter, you might want to consider increasing them, although
I've used similar setups in the past without issues (I've never used
the opendkim milter, I rolled my own:).

> All things considered, I may just decide to temporarily set the OnFail
> option to Accept in my clamav-milter.conf file. It's certainly not an
> ideal solution though.

It certainly isn't.  As it happens a colleague in the USA mentioned
that he occasionally has to restart clamd too.  Except when I've done
something daft I don't recall ever having to do that, so I'm starting
to wonder if there's something not going on here that _is_ going on
elsewhere.  If you'd like to let me have a copy of your clamd.conf
privately I'll compare it with my own and my colleague's to see if
anything obvious meets the eye.  I've tweaked our filter rules so mail
from your address to my list address won't (shouldn't:) be rejected.

-- 

73,
Ged.



More information about the clamav-users mailing list