It looks like your client issues STREAM command to clamd, and not connects to port replied.
This may happen due to timeouts in your client. I.e.: your client connects, issues STREAM, then clamd waits for free working thread, your client timeouts, clamd's working threads opens sockets and waits 120 secs for already timeouted client. So, any scanning attempt locks 1 working thread for 120 secs. Once entered, this state will not be leaved until your load drops below MaxThreads / ReadTimeout scans per second.
I believe his app is timing out, and that is probably a good thing. In clamav 0.83
the behavior of clamd would cause long delays when a database reload was needed.
See http://article.gmane.org/gmane.comp.security.virus.clamav.devel/1646/match=less+stressful
On Thu, 17 Mar 2005, Colin MacDonald wrote:
> Hi.
>
> I've seen the following in clamd logs and it looks like some kind of > bug:
>
> Wed Mar 16 15:40:02 2005 -> Reading databases from /usr/local/clamav/db
> Wed Mar 16 15:40:03 2005 -> Database correctly reloaded (31605 viruses)
> Wed Mar 16 15:42:03 2005 -> ERROR: ScanStream: accept timeout.
This was logged smce your app timed out waiting for the PORT response.
> Naturally, this doesn't happen every time the databases are re-read...
> I'm using v0.83 on Redhat 8. The client is my own code, but it works > fine.
> I can't actually say whether or not clamd still detects viruses at this
> point, because I've only seen this on our beta test site, not on my
> development setup.
>
> Is this a known issue?
>
> I'll try to replicate this in my development environment, but any clues
> as to what might cause this in the meantime would be appreciated.
Tomasz has accepted the suggested patch around March 7.
Try a more recent snapshot and see if the problem has gone away.
- Mark Pizzolato
_______________________________________________ http://lurker.clamav.net/list/clamav-devel.html
