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

[Groach]

FWIW, if I may offer opinion:  I would agree with Alex with the need to 
source out better unofficial databases (such as sanesecurity, 
securiteinfo etc):  clam definitions are inherently slow on the uptake 
of new threats, taking a day or more (at best) and in some cases never 
(ive demonstrated this in other posts on this mail list). (I dont know 
if I am breaking a rule here by advertising - apologies if so but I am 
not affiliated in any way) sanesecurity definitions have proven 
invaluable and EXTREMELY responsive regarding zero-hour threats 
especially to the crytolocker and DOC-macro based threats (REALLY being 
'zero hour' coverage by definition).  (In my opinion. I also believe 
that they the ONLY way you can use ClamAv is if you employ 3rd party 
definitions given that most threats are at its highest danger level just 
hours after release and its simply unproductive releasing signatures to 
catch them days later (or never!).  Clam always needs supplementing with 
either 3rd party definitions (which Alex has), another realtime scanning 
commercial Av product (which Alex has), or both (which Alex has).

I can bery well imagine, though that 9 million definitions are excessive 
and probably over 70% have no point in existing any more (threat 
probably been and gone).

Alex, I use standard defs and sane only (to cut down on definitions) and 
have excellent coverage without the slow 'startup times' that you have 
mentioned whilst being backed up with Bitdefender on the client PC's.  
Might be worth changing your signatures if they are increasing your 
start time without adding any noticeable benefit (or at least 
experiemnting to see if it makes a difference.  You can always revert 
back to your current choice....and your "  ' ' response  " error.  ;-)

Jim

On 22/02/2016 15:08, Alex wrote:
> Hi,
>
>> Can’t be of much help with your primary issue, but to answer one or your questions, the official ClamAV database is a bit over 4 million.  I can’t conceive of a situation where you would need every conceivable unofficial database, but then I have no idea what you are doing with your setup, other than it would appear to have some relationship to e-mail service.
> It comes from complaints from users about zero-day and cryptowall
> viruses making it through the mail gateway, then being caught by
> Symantec as it reaches Exchange. Or a compromise being traced back to
> not having caught a virus a few hours earlier.
>
>> There was a discussion less than a month ago concerning minimum essential database subscriptions, so
>> suggest you search around in the archive for that thread
>> <clamav-user archives>.
> I'll search around, thanks.
>
> Assistance with my other issues would still very much be appreciated.
>
> Thanks,
> Alex
>
>> -Al-
>>
>> On Sun, Feb 21, 2016 at 03:40 PM, Alex wrote:
>>> Hi,
>>>
>>> I have a clamav-0.99-2 installation on fedora23 and periodically I
>>> receive a message when running clamav-notify-servers after having run
>>> freshclam that reports:
>>>
>>> # clamav-notify-servers
>>> clamd server '/var/run/clamd.amavisd/clamd.sock' gave '' response
>>>
>>> I have a script that periodically rsyncs the malwarepatrol db to the
>>> /var/lib/clamav directory then runs the clamav-notify-servers. I
>>> believe the problem is related to this occurring at the same time as
>>> the regular freshclam-sleep script running clamav-notify-servers.
>>>
>>> Is this the intended behavior for clamd?
>>>
>>> I have about 9M signatures now, so it appears to take a long time to
>>> reload the database every time the clamav-notify-servers signal is
>>> sent.
>>>
>>> Can someone provide some advice on the best way to do this? I don't
>>> think I can control the timing of the clamav-notify-servers to make
>>> sure it doesn't happen while another instance occurs. Should I just
>>> redirect the output to /dev/null?
>>>
>>> Is it common to have 9M entries?
>>>
>>> It looks to take about 30s to reload the database:
>>> Feb 21 03:22:15 mail03 clamd[1006]: Reading databases from /var/lib/clamav
>>> Feb 21 03:22:46 mail03 clamd[1006]: Database correctly reloaded
>>> (8888331 signatures)
>>> Feb 21 03:22:46 mail03 clamd[1006]: Client disconnected (FD 23)
>>>
>>> This is on a six-core 3Ghz system on SSD disks.
>>>
>>> [root at mail03 clamav]# ls
>>> badmacro.ndb                 foxhole_filename.cdb  phishtank.ndb
>>>    spamattach.hdb
>>> blurl.ndb                    foxhole_generic.cdb   porcupine.hsb
>>>    spamimg.hdb
>>> bofhland_cracked_URL.ndb     hackingteam.hsb       porcupine.ndb
>>>    spam.ldb
>>> bofhland_malware_attach.hdb  javascript.ndb        rogue.hdb
>>>    spearl.ndb
>>> bofhland_malware_URL.ndb     junk.ndb              safebrowsing.cvd
>>>    spear.ndb
>>> bofhland_phishing_URL.ndb    jurlbla.ndb           sanesecurity.ftm
>>>    winnow.attachments.hdb
>>> my_sigwhitelist.gdb         jurlbl.ndb            scamnailer.ndb
>>>   winnow_bad_cw.hdb
>>> my_sigwhitelist.ign2        lott.ndb              scam.ndb
>>>   winnow.complex.patterns.ldb
>>> my_sigwhitelist.wdb         main.cvd
>>> securiteinfoascii.hdb  winnow_extended_malware.hdb
>>> bytecode.cld                 malwarehash.hsb       securiteinfo.hdb
>>>    winnow_malware.hdb
>>> crdfam.clamav.hdb            malwarepatrol.ndb
>>> securiteinfohtml.hdb   winnow_malware_links.ndb
>>> create_sig.txt               mirrors.dat           securiteinfo.ign2
>>>    winnow_phish_complete_url.ndb
>>> daily.cld                    phish.ndb             sigwhitelist.ign2
>>>    winnow_spam_complete.ndb
>>>
>>> I think the commercial securiteinfo databases are entirely too large
>>> and don't perform very well.
>>>
>>> Of course I could cut down on the databases, but I'm more interested
>>> in finding out why clamd produces the error message when multiple
>>> signals are sent.
>>>
>>> Thanks,
>>> Alex