[clamav-users] clamd server '/var/run/clamd.amavisd/clamd.sock' gave '' response

Dennis Peterson dennispe at inetnw.com
Thu May 26 08:33:43 EDT 2016

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 

On 2/22/16 12:48 PM, Alex wrote:
> Hi,
> On Mon, Feb 22, 2016 at 1:57 PM, Joel Esler (jesler) <jesler at 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-stopspammingme at yahoo.com<mailto:groachmail-stopspammingme at 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

More information about the clamav-users mailing list