On Thu, 2005-03-17 at 10:31 +0000, Colin MacDonald wrote:
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. Wed Mar 16 15:42:03 2005 -> ERROR: ScanStream: accept timeout. Wed Mar 16 15:42:03 2005 -> ERROR: ScanStream: accept timeout. Wed Mar 16 15:42:03 2005 -> ERROR: ScanStream: accept timeout. Wed Mar 16 15:42:03 2005 -> ERROR: ScanStream: accept timeout. ... and so on, with an 'accept timeout' error for each thread.
I'm using v0.83 on Redhat 8. The client is my own code, but it works fine.
Well obviously it doesn't. I suspect you are either parsing the port number incorrectly, or your system is blocking connections to high port numbers.
No, actually it does. The piece of code that issues the STREAM command and receives the port number has successfully scanned many thousands of files by now. It works fine.
If you'd taken the time to read through the original post before assuming auto-superiority mode you'd see that the problem happens only occasionally, happens simultaneously on every thread that clamd is running, and only happens after a database reload. What is it about that, fairly narrow, set of circumstances that suggests that the client code is faulty?
In the trace above clamd was running at the configured maximum thread count (50 in this instance); it could be that the problem only occurs when all threads have been activated. I haven't checked the code to see if threads are created on demand or all at once.
Colin MacDonald
_______________________________________________ http://lurker.clamav.net/list/clamav-devel.html
