Forgot to respond to this earlier - this can happen if an update begins before a
previous update finishes. And this can happen if you have multiple scripts
fetching signatures from multiple vendors. Some scripts have a built in random
delay that attempts to prevent every user from updating on the hour, for
example, but because these scripts are not aware of each other the opportunity
exists that there will be overlap.
The tools communicate with the clamd daemon via a unix or tcp socket and sent
the word "PING". The daemon should respond with "PONG" and it will unless it is
busy. That can cause the connection to timeout without a response and that
produces the error message you see.
There is probably a more elegant way of handling this short of a serializing
layer, but since the purpose of the script is to request a reload and not be
part of a service monitoring tool, I think the correct response is to give up
quietly and not obsess. Delaying until the previous reload is completed then
launching another reload simply extends the time the service is unavailable.
Summary: For the rare occasion that multiple vendors have new signatures
available at the same time, the possibility exists that the fetching processes
will result in an overlap of reload requests. The clamd daemon becomes
disfunctional during a reload so it is in everyone's interest to minimize the
number of this these are called. This suggests the reload request should be
isolated from the fetch process so that excessive reloads are not requested - a
simple serializing process can manage this to avoid a self-induced DOS.
Especially problematic on Solaris SPARC systems and systems with memory/cpu
limitations.
dp
On 2/22/16 12:48 PM, Alex wrote:
Hi,
On Mon, Feb 22, 2016 at 1:57 PM, Joel Esler (jesler) <jes...@cisco.com> wrote:
Gentlemen. We get the point. We’re working on it. I had a conversation with
the malware lead
last week to see what we can do here.
Can you help with my original question about:
clamd server '/var/run/clamd.amavisd/clamd.sock' gave '' response
Is this expected, when clamav-notify-servers is run while clamd is
re-reading the databases?
Can someone tell me if this happens on their system too? It was a bug
a long time ago, but thought it was fixed. It's just started again.
On Feb 22, 2016, at 12:06 PM, Groach
<groachmail-stopspammin...@yahoo.com<mailto:groachmail-stopspammin...@yahoo.com>>
wrote:
I dont think there is any 'cause' to be had (that the unofficial signatures
found threats and that the official ones didnt) other than ClamAV signatures
are too few, too ineffective and more importantly too late.
I never saw this message. Was this posted to the list?
I've found the sanesecurity rules to work well. The securiteinfo rules
are horrible. I'd never expect to only use the default clamav rules.
Thanks,
Alex
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
