On 2011-10-10 19:15, Alex wrote: > Hi, > >>>>> I have a fedora15 x86_64 box with clamav-0.97.2, postfix-2.8.4, and >>>>> amavisd-new-2.6.6 with spamassassin-3.3.2 that has been running fine >>>>> for quite a while. Recently, clamd has died with an error similar to >> >> Was it clamd that died or both clamd and clamscan? > > It looks like both: > > Oct 10 01:11:02 mail02 amavis[31956]: (31956-07-4) ClamAV-clamd: Can't > send to socket /var/spool/amavisd/clamd.sock: Transport endpoint is > not connected, retrying (1) > > And here is clamd failing: > > Oct 10 12:03:29 mail02 amavis[14313]: (14313-03-6) (!)ClamAV-clamscan > av-scanner FAILED: /usr/bin/clamscan unexpected exit 2, > output="LibClamAV Error: cli_loadhash: Problem parsing database at > line 662180\nLibClamAV Error: Can't load main.mdb: Malformed > database\nLibClamAV Error: cli_tgzload: Can't load main.mdb\nLibClamAV > Error: Can't load /var/lib/clamav/main.cvd: Malformed database\nERROR: > Malformed database" at (eval 91) line 596.
main.cvd was last updated in 2010, and it is definitely not broken. So this random database parsing failure can be 2 things: - hardware issue - memory corruption bug in libclamav For the 1st all I can suggest is to run memtest again, but you probably can't afford to take down a production server just to do that. There is another one, memtester which can be run from userspace without rebooting, you can try that. Of course it could be some other HW problem, but RAM is the one that fails most often. For the 2nd you can try running clamscan under valgrind and see if it reports any warnings, i.e. valgrind clamscan /dev/null. > > I notice that it's not always the same database or line number that it > is failing on, and it's now just happened again, so it's now more > frequent. > > I suppose it could be a hardware problem, but it's a kvm virtual > machine running on new x86_64 Xeon hardware that was stress tested > before putting into production. It ran without any difficulties for > probably a week prior to the first occurrence of the problem. The next time this happens (or if you can still reproduce the problem) take a backup of the database directory (cp -a), upload it somewhere, open a bug and put the link there, will take a look if there's anything wrong with the parsing code. Best regards, --Edwin _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
