Re: [Clamav-users] Re: Chronic MD5 Verification Errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 17, 2007 at 10:54:53AM -0500, Edward Dam wrote: >Tue Jan 16 22:40:09 2007 -> SelfCheck: Database status OK. Reloading >anyway. >Tue Jan 16 22:40:09 2007 -> Reading databases from /var/clamav >Tue Jan 16 22:40:09 2007 -> >/var/spool/qmailscan/tmp/LINUXSERV11690052074934404/orig-LINUXSERV11690052074934404: >HTML.Phishing.Bank-627 FOUND >Tue Jan 16 22:40:10 2007 -> ERROR: reload db failed: MD5 verification error You wouldn't by any chance happen to have quotas enabled for this partition and are bumping up against some kind of limit for the user that clamav is running as... - -- Regards... Todd We should not be building surveillance technology into standards. Law enforcement was not supposed to be easy. Where it is easy, it's called a police state. -- Jeff Schiller on NANOG Linux kernel 2.6.17-5mdv 4 users, load average: 0.30, 0.07, 0.02 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFrp7JY2VBGxIDMLwRAs/IAJ49q90wDwWPlMUE9mmNDDgmhQRPSgCfRUp+ N1iV2wTMsXVVZck8b9oG4yQ= =GvSU -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
On 1/17/07, Stephen Gran <[EMAIL PROTECTED]> wrote:
On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam said:
> On 1/2/07, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >On 20/12/06 16:49, Edward Dam wrote:
> >> On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >>>
> >>> #if 0 /* original */
> >>> logg("SelfCheck: Database status OK.\n");
> >>> return NULL;
> >>> #else /* temporary test */
> >>> logg("SelfCheck: Database status OK. Reloading
anyway.\n");
> >>> return root;
> >>> #endif
> >>>
> >>> This will force the self-check to reload the database files even if
> >>> nothing has changed. Then if you get MD5 errors randomly after this
> >>> message in the logs, you'll know it has nothing to do with
freshclam,
> >>> and more to do with random disk read/write errors.
> >>
> >> I've done this code change, and the mail system just died.
> >> Here's the relevant clip from the clamd log:
> >>
> >> Wed Dec 20 09:53:33 2006 -> SelfCheck: Database status OK. Reloading
anyway.
> >> Wed Dec 20 09:53:33 2006 -> Reading databases from /var/clamav
> >> Wed Dec 20 09:53:33 2006 -> ERROR: reload db failed: MD5 verification
error
> >
> >Sorry for the tardiness of this reply! Those logs appear to be
> >generated as a result of clamd's scheduled self-check, as no changes to
> >the timestamps of the database files were detected (that would result
in
> >"SelfCheck: Database modification detected. Forcing reload.").
> >
> >However, there is a small possibility that freshclam could be updating
> >the database files during clamd's scheduled self-check in such a way
> >that clamd does not notice that the timestamps have changed, but due to
> >the code change is reloading the (possibly modified) database files
> >anyway. To rule out this possibility, it would be necessary to look at
> >the freshclam logs to see when it last notified clamd about the updated
> >files.
Unlikely - freshclam writes to a temp file, and verifies that before
doing anything to the main file. The OP can verify by correlating
timestamps of freshclam download attempts with the last crash on Dec
20th, however.
So, OP - can you supply logfiles for both clamd and freshclam around the
times of the crash? It really looks to me like freshclam is verifying
the md5 signature, and immediately after, clamd is failing to do so.
Very, very odd.
--
--
| Stephen Gran | Nothing is so often irretrievably
|
| [EMAIL PROTECTED] | missed as a daily opportunity. --
|
| http://www.lobefin.net/~steve |
Ebner-Eschenbach|
--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFrkMxSYIMHOpZA44RAunsAJoDTo2iflIc8n2oUyhFDPpe1PlCGgCeMZ9H
Js05ijZa+8YNb0PaThug0Y0=
=tFfx
-END PGP SIGNATURE-
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
As requested, here are log snippets from the latest crash.
Freshclam.log:
Here it gets a successful update and notifies clam:
Jan 16 17:01:00 LINUXSERV CROND[17998]: (root) CMD (run-parts
/etc/cron.hourly)
--
freshclam daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i686)
ClamAV update process started at Tue Jan 16 18:36:34 2007
main.cvd is up to date (version: 42, sigs: 83951, f-level: 10, builder:
tkojm)
daily.cvd updated (version: 2459, sigs: 3178, f-level: 9, builder: sven)
Database updated (87129 signatures) from db.ca.clamav.net (IP:
209.139.239.158)
Clamd successfully notified about the update.
... cut to the section where it dies:
--
Jan 17 07:01:00 LINUXSERV CROND[11334]: (root) CMD (run-parts
/etc/cron.hourly)
--
ClamAV update process started at Wed Jan 17 07:30:32 2007
main.cvd updated (version: 42, sigs: 83951, f-level: 10, builder: tkojm)
daily.cvd updated (version: 2459, sigs: 3178, f-level: 9, builder: sven)
Database updated (87129 signatures) from db.ca.clamav.net (IP:
209.172.34.149)
ERROR: Clamd was NOT notified: Can't connect to clamd on 127.0.0.1:3310
So you see that clam was down at 7:30am.
Here's the relevant snippet from clamd.log
Jan 16 22:01:00 LINUXSERV CROND[4087]: (root) CMD (run-parts
/etc/cron.hourly)
Tue Jan 16 22:40:09 2007 ->
/var/spool/qmailscan/tmp/LINUXSERV11690052074934404/1169005209.4406-
0.LINUXSERV: HTML.Phishing.Bank-627 FOUND
Tue Jan 16 22:40:09 2007 -> SelfCheck: Database status OK. Reloading
anyway.
Tue Jan 16 22:40:09 2007 -> Reading databases from /var/clamav
Tue Jan 16 22:40:09 2007 ->
/var/spool/qmailscan/tmp/LINUXSERV11690052074934404/orig-LINUXSERV11690052074934404:
HTML.Phishing.Bank-627 FOUND
Tue Jan 16 22:40:10 2007 -> ERROR: reload db failed: MD5 verification error
S
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
On Wed, 17 Jan 2007 08:49:14 -0500 "Edward Dam" <[EMAIL PROTECTED]> wrote: > Thanks everyone, for the replies and help. > > At this point, I am doing the only thing I can - removing clamav from the > system, and using a mail security hardware device in front of the mail > server. > > ClamAV is the *ONLY* thing repeatedly dying on this heavily used server. > This server is a MySQL server, Samba Server, DHCP server, and Intranet web > server. EVERYTHING else works fine, all the time. ClamAV dies almost daily, > hanging the whole email system. > > I've now replaced RAM, CPUs and RAID controller in the system - no change in > the problem. It's clear to me clamAV isn't getting along with something, > somewhere.. but the only error I have to go by is > > " reload db failed: MD5 verification error " > > > ...and the cause remains a mystery.. but I don't have the time or budget to > go the "process of elimination" route, as the powers that be are at a point Hello Ed, since the problem looks really weird I can offer you help and if you could grant me with a user level access to the problematic machine I'd be very keen to do some debugging. Regards, -- oo. Tomasz Kojm <[EMAIL PROTECTED]> (\/)\. http://www.ClamAV.net/gpg/tkojm.gpg \..._ 0DCA5A08407D5288279DB43454822DC8985A444B //\ /\ Wed Jan 17 16:37:12 CET 2007 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam said:
> On 1/2/07, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >On 20/12/06 16:49, Edward Dam wrote:
> >> On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >>>
> >>> #if 0 /* original */
> >>> logg("SelfCheck: Database status OK.\n");
> >>> return NULL;
> >>> #else /* temporary test */
> >>> logg("SelfCheck: Database status OK. Reloading anyway.\n");
> >>> return root;
> >>> #endif
> >>>
> >>> This will force the self-check to reload the database files even if
> >>> nothing has changed. Then if you get MD5 errors randomly after this
> >>> message in the logs, you'll know it has nothing to do with freshclam,
> >>> and more to do with random disk read/write errors.
> >>
> >> I've done this code change, and the mail system just died.
> >> Here's the relevant clip from the clamd log:
> >>
> >> Wed Dec 20 09:53:33 2006 -> SelfCheck: Database status OK. Reloading
> >> anyway.
> >> Wed Dec 20 09:53:33 2006 -> Reading databases from /var/clamav
> >> Wed Dec 20 09:53:33 2006 -> ERROR: reload db failed: MD5 verification error
> >
> >Sorry for the tardiness of this reply! Those logs appear to be
> >generated as a result of clamd's scheduled self-check, as no changes to
> >the timestamps of the database files were detected (that would result in
> >"SelfCheck: Database modification detected. Forcing reload.").
> >
> >However, there is a small possibility that freshclam could be updating
> >the database files during clamd's scheduled self-check in such a way
> >that clamd does not notice that the timestamps have changed, but due to
> >the code change is reloading the (possibly modified) database files
> >anyway. To rule out this possibility, it would be necessary to look at
> >the freshclam logs to see when it last notified clamd about the updated
> >files.
Unlikely - freshclam writes to a temp file, and verifies that before
doing anything to the main file. The OP can verify by correlating
timestamps of freshclam download attempts with the last crash on Dec
20th, however.
So, OP - can you supply logfiles for both clamd and freshclam around the
times of the crash? It really looks to me like freshclam is verifying
the md5 signature, and immediately after, clamd is failing to do so.
Very, very odd.
--
--
| Stephen Gran | Nothing is so often irretrievably |
| [EMAIL PROTECTED] | missed as a daily opportunity. -- |
| http://www.lobefin.net/~steve | Ebner-Eschenbach|
--
signature.asc
Description: Digital signature
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
On 1/17/07, Todd Lyons <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam wrote: >Thanks again for all your help. Maybe once clamAV matures, it will be a >better fit for my needs, but until then I need to remove it, as it's the >cause of my headaches. I would disagree on the "it's not mature" inference. We use it on a load balanced system with each mail server handling 60K messages per day (CentOS 4.4) and have never had clamd die. There are another 200K or so a day that get rejected due to various RBL's but clamav/spamassassin never see those because it's blocked at HELO time. Occassionally spamass-milter wants to get hung in a weird state, but clamd and clamav-milter are rock solid (we're a sendmail shop by the way). However, since it is on a pretty busy machine, if moving your virus scanning off that busy machine fixes your problem, then you are doing the right thing for your needs. Congrats on not having to use Exchange! - -- Regards... Todd Exponential problems need logarithmic solutions. --Eddy Dreger Linux kernel 2.6.17-5mdv 3 users, load average: 0.01, 0.05, 0.00 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFrj72Y2VBGxIDMLwRAi5DAJ9x8HA1OZ35hlLIa53dBnBxGjgAkwCfbaUw ntG/IZPWv6Z94ryJpF27XNA= =Cgk+ -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html I do apologize about the "mature" statement - I am just very frustrated on this issue. What I was referring to was the pre "1.0" state of clamav - hence not "mature" or "final"... it wasn't my intention to make it sound derogative towards the product or developers. My apologies once again. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam wrote: >Thanks again for all your help. Maybe once clamAV matures, it will be a >better fit for my needs, but until then I need to remove it, as it's the >cause of my headaches. I would disagree on the "it's not mature" inference. We use it on a load balanced system with each mail server handling 60K messages per day (CentOS 4.4) and have never had clamd die. There are another 200K or so a day that get rejected due to various RBL's but clamav/spamassassin never see those because it's blocked at HELO time. Occassionally spamass-milter wants to get hung in a weird state, but clamd and clamav-milter are rock solid (we're a sendmail shop by the way). However, since it is on a pretty busy machine, if moving your virus scanning off that busy machine fixes your problem, then you are doing the right thing for your needs. Congrats on not having to use Exchange! - -- Regards... Todd Exponential problems need logarithmic solutions. --Eddy Dreger Linux kernel 2.6.17-5mdv 3 users, load average: 0.01, 0.05, 0.00 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFrj72Y2VBGxIDMLwRAi5DAJ9x8HA1OZ35hlLIa53dBnBxGjgAkwCfbaUw ntG/IZPWv6Z94ryJpF27XNA= =Cgk+ -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
On 1/2/07, Ian Abbott <[EMAIL PROTECTED]> wrote:
On 20/12/06 16:49, Edward Dam wrote:
> On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
>>
>> On 13/12/06 14:28, Edward Dam wrote:
>> > Hi Ian,
>> >
>> > Thanks for the help.
>> >
>> > I've only got the main.cvd and daily.cvd databases in use right now,
>> > until I
>> > get this sorted out - so it's not a 3rd party db or script issue.
>> >
>> > Here's basically what happens.
>> >
>> > Freshclam downloads the updates, then notifes clamd to re-read the
>> > databases. Then my log looks like this:
>> >
>> > Wed Dec 13 06:05:04 2006 -> SelfCheck: Database status OK.
>> >
>> > Wed Dec 13 06:28:57 2006 -> Reading databases from /var/clamav
>> >
>> > Wed Dec 13 06:28:57 2006 -> ERROR: reload db failed: MD5 verification
>> error
>> >
>> >
>> > At this point mail is dead, and I have to delete the CVD files in
>> > /var/clamav and re-run freshclam to get new ones, then manually start
>> > clamav. All is well, until it happens again.
>> >
>> > The frustrating part is that it's so intermittent. It doesn't happen
>> every
>> > time. It doesn't happen at a regular interval. It's completely
random,
>> with
>> > the exception that it will probably once a day - or once every 2nd
day
>> on
>> > the very high end.
>>
>> What normally happens during the self-check is that the database
>> directory entries are read, but the files in the database directory are
>> not reloaded unless the directory entries have changed. This means
that
>> the "SelfCheck: Database status OK." message does not mean the database
>> files were read okay, rather they weren't read at all.
>>
>> May I suggest a minor code change for diagnostic purposes? In
>> clamd/server-th.c, look for the lines:
>>
>> logg("SelfCheck: Database status OK.\n");
>> return NULL;
>>
>> and change them to:
>>
>> #if 0 /* original */
>> logg("SelfCheck: Database status OK.\n");
>> return NULL;
>> #else /* temporary test */
>> logg("SelfCheck: Database status OK. Reloading
anyway.\n");
>> return root;
>> #endif
>>
>> This will force the self-check to reload the database files even if
>> nothing has changed. Then if you get MD5 errors randomly after this
>> message in the logs, you'll know it has nothing to do with freshclam,
>> and more to do with random disk read/write errors.
>
>
> I've done this code change, and the mail system just died.
>
> Here's the relevant clip from the clamd log:
>
> Wed Dec 20 09:53:33 2006 -> SelfCheck: Database status OK. Reloading
> anyway.
> Wed Dec 20 09:53:33 2006 -> Reading databases from /var/clamav
> Wed Dec 20 09:53:33 2006 -> ERROR: reload db failed: MD5 verification
error
Sorry for the tardiness of this reply! Those logs appear to be
generated as a result of clamd's scheduled self-check, as no changes to
the timestamps of the database files were detected (that would result in
"SelfCheck: Database modification detected. Forcing reload.").
However, there is a small possibility that freshclam could be updating
the database files during clamd's scheduled self-check in such a way
that clamd does not notice that the timestamps have changed, but due to
the code change is reloading the (possibly modified) database files
anyway. To rule out this possibility, it would be necessary to look at
the freshclam logs to see when it last notified clamd about the updated
files.
If we assume for the moment that freshclam was not updating the database
files during clamd's scheduled self-check (which can be verified by
checking the clamd and freshclam logs), then it appears that the
database files have become corrupted but their timestamps have not
changed. Either the new database files downloaded by freshclam are
being corrupted while they are being physically written to the disk, or
something else is clobbering them afterwards. (Yes I know freshclam
checks the downloaded database files before using them, but as it has
just written the files, it might be the data back from a cache
maintained by the OS, rather than from the physical disk. In this case,
the corruption would not show up until the cache entries have been
flushed by the OS.)
--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Thanks everyone, for the replies and help.
At this point, I am doing the only thing I can - removing clamav from the
system, and using a mail security hardware device in front of the mail
server.
ClamAV is the *ONLY* thing repeatedly dying on this heavily used server.
This server is a MySQL server, Samba Server, DHCP server, and Intranet web
server. EVERYTHING else works fine, all the time. ClamAV dies almost daily,
hanging the whole email system.
I've now replaced RAM, CPUs a
[Clamav-users] Re: Chronic MD5 Verification Errors
On 20/12/06 16:49, Edward Dam wrote:
On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
On 13/12/06 14:28, Edward Dam wrote:
> Hi Ian,
>
> Thanks for the help.
>
> I've only got the main.cvd and daily.cvd databases in use right now,
> until I
> get this sorted out - so it's not a 3rd party db or script issue.
>
> Here's basically what happens.
>
> Freshclam downloads the updates, then notifes clamd to re-read the
> databases. Then my log looks like this:
>
> Wed Dec 13 06:05:04 2006 -> SelfCheck: Database status OK.
>
> Wed Dec 13 06:28:57 2006 -> Reading databases from /var/clamav
>
> Wed Dec 13 06:28:57 2006 -> ERROR: reload db failed: MD5 verification
error
>
>
> At this point mail is dead, and I have to delete the CVD files in
> /var/clamav and re-run freshclam to get new ones, then manually start
> clamav. All is well, until it happens again.
>
> The frustrating part is that it's so intermittent. It doesn't happen
every
> time. It doesn't happen at a regular interval. It's completely random,
with
> the exception that it will probably once a day - or once every 2nd day
on
> the very high end.
What normally happens during the self-check is that the database
directory entries are read, but the files in the database directory are
not reloaded unless the directory entries have changed. This means that
the "SelfCheck: Database status OK." message does not mean the database
files were read okay, rather they weren't read at all.
May I suggest a minor code change for diagnostic purposes? In
clamd/server-th.c, look for the lines:
logg("SelfCheck: Database status OK.\n");
return NULL;
and change them to:
#if 0 /* original */
logg("SelfCheck: Database status OK.\n");
return NULL;
#else /* temporary test */
logg("SelfCheck: Database status OK. Reloading anyway.\n");
return root;
#endif
This will force the self-check to reload the database files even if
nothing has changed. Then if you get MD5 errors randomly after this
message in the logs, you'll know it has nothing to do with freshclam,
and more to do with random disk read/write errors.
I've done this code change, and the mail system just died.
Here's the relevant clip from the clamd log:
Wed Dec 20 09:53:33 2006 -> SelfCheck: Database status OK. Reloading
anyway.
Wed Dec 20 09:53:33 2006 -> Reading databases from /var/clamav
Wed Dec 20 09:53:33 2006 -> ERROR: reload db failed: MD5 verification error
Sorry for the tardiness of this reply! Those logs appear to be
generated as a result of clamd's scheduled self-check, as no changes to
the timestamps of the database files were detected (that would result in
"SelfCheck: Database modification detected. Forcing reload.").
However, there is a small possibility that freshclam could be updating
the database files during clamd's scheduled self-check in such a way
that clamd does not notice that the timestamps have changed, but due to
the code change is reloading the (possibly modified) database files
anyway. To rule out this possibility, it would be necessary to look at
the freshclam logs to see when it last notified clamd about the updated
files.
If we assume for the moment that freshclam was not updating the database
files during clamd's scheduled self-check (which can be verified by
checking the clamd and freshclam logs), then it appears that the
database files have become corrupted but their timestamps have not
changed. Either the new database files downloaded by freshclam are
being corrupted while they are being physically written to the disk, or
something else is clobbering them afterwards. (Yes I know freshclam
checks the downloaded database files before using them, but as it has
just written the files, it might be the data back from a cache
maintained by the OS, rather than from the physical disk. In this case,
the corruption would not show up until the cache entries have been
flushed by the OS.)
--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
On Wednesday 13 December 2006 11:37 am, Bill Landry wrote: > > To avoid these problems, freshclam and the third party update scripts > > could be run sequentially from a single cron job, rather than running > > freshclam as a daemon. > > This is exactly what I do. Via cron.hourly (rather than freshclam > daemon) I check for new files, if new then download and test the any new > SaneSecurity and MSRBL signature files, then run freshclam. Work well > here. > Bill, I'm using the script you posted awhile back for the MSRBL and SaneSecurity sigs and its working great. -- Chris http://learn.to/quote pgp87w7nYNk04.pgp Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
On 13/12/06 14:28, Edward Dam wrote:
> Hi Ian,
>
> Thanks for the help.
>
> I've only got the main.cvd and daily.cvd databases in use right now,
> until I
> get this sorted out - so it's not a 3rd party db or script issue.
>
> Here's basically what happens.
>
> Freshclam downloads the updates, then notifes clamd to re-read the
> databases. Then my log looks like this:
>
> Wed Dec 13 06:05:04 2006 -> SelfCheck: Database status OK.
>
> Wed Dec 13 06:28:57 2006 -> Reading databases from /var/clamav
>
> Wed Dec 13 06:28:57 2006 -> ERROR: reload db failed: MD5 verification
error
>
>
> At this point mail is dead, and I have to delete the CVD files in
> /var/clamav and re-run freshclam to get new ones, then manually start
> clamav. All is well, until it happens again.
>
> The frustrating part is that it's so intermittent. It doesn't happen
every
> time. It doesn't happen at a regular interval. It's completely random,
with
> the exception that it will probably once a day - or once every 2nd day
on
> the very high end.
What normally happens during the self-check is that the database
directory entries are read, but the files in the database directory are
not reloaded unless the directory entries have changed. This means that
the "SelfCheck: Database status OK." message does not mean the database
files were read okay, rather they weren't read at all.
May I suggest a minor code change for diagnostic purposes? In
clamd/server-th.c, look for the lines:
logg("SelfCheck: Database status OK.\n");
return NULL;
and change them to:
#if 0 /* original */
logg("SelfCheck: Database status OK.\n");
return NULL;
#else /* temporary test */
logg("SelfCheck: Database status OK. Reloading anyway.\n");
return root;
#endif
This will force the self-check to reload the database files even if
nothing has changed. Then if you get MD5 errors randomly after this
message in the logs, you'll know it has nothing to do with freshclam,
and more to do with random disk read/write errors.
Have you tried replacing the HD cable? You never mentioned it.
Certainly for P-ATA disks, don't expect much in the way of error
detection unless Ultra DMA mode is being used (and even then, CRC error
checking is only performed for data packets, not for command and status
packets). It's unlikely to be a problem for S-ATA disks though.
--
-=( Ian Abbott @ MEV Ltd.E-mail: < [EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
I've done this code change, and the mail system just died.
Here's the relevant clip from the clamd log:
Wed Dec 20 09:53:33 2006 -> SelfCheck: Database status OK. Reloading anyway.
Wed Dec 20 09:53:33 2006 -> Reading databases from /var/clamav
Wed Dec 20 09:53:33 2006 -> ERROR: reload db failed: MD5 verification error
maillog:
Dec 20 09:53:44 LINUXSERV X-Qmail-Scanner-1.25:
[LINUXSERV116662642449315041] clamdscan: corrupt or unknown clamd
scanner error or memory/resource/perms problem - exit status 512/2
Dec 20 09:54:46 LINUXSERV X-Qmail-Scanner-1.25:
[LINUXSERV116662648649315087] clamdscan: corrupt or unknown clamd
scanner error or memory/resource/perms problem - exit status 512/2
messages:
Dec 20 09:53:33 LINUXSERV clamd[1053]: SelfCheck: Database status OK.
Reloading anyway.
Dec 20 09:53:33 LINUXSERV clamd[1053]: Reading databases from /var/clamav
Dec 20 09:53:33 LINUXSERV clamd[1053]: reload db failed: MD5 verification error
Dec 20 09:54:49 LINUXSERV X-Qmail-Scanner-1.25:
[LINUXSERV116662648949315099] clamdscan: corrupt or unknown clamd
scanner error
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
Hi Ian,
Thanks again. I will make the modifications to the server-th.c file and let
you know.
As far as the HD cable goes, this is a server with 3 x 36GB 10,000 RPM SCSI
drives in RAID 5 on an adaptec 2120s raid controller. (at the latest bios
revision.. yep, tried that as well).
The thing that makes me rule out disk I/O is that this is the only error on
the whole system. There is a decent amount of data (40GB or so shared via
samba) on this same array, which gets a lot of traffic - but no errors in
the logs, no performance issues, nada. All is well there. If this were a
disk issue, I'd think we'd be having a lot more problems on that side than
on the clamav side.
On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
What normally happens during the self-check is that the database
directory entries are read, but the files in the database directory are
not reloaded unless the directory entries have changed. This means that
the "SelfCheck: Database status OK." message does not mean the database
files were read okay, rather they weren't read at all.
May I suggest a minor code change for diagnostic purposes? In
clamd/server-th.c, look for the lines:
logg("SelfCheck: Database status OK.\n");
return NULL;
and change them to:
#if 0 /* original */
logg("SelfCheck: Database status OK.\n");
return NULL;
#else /* temporary test */
logg("SelfCheck: Database status OK. Reloading anyway.\n");
return root;
#endif
This will force the self-check to reload the database files even if
nothing has changed. Then if you get MD5 errors randomly after this
message in the logs, you'll know it has nothing to do with freshclam,
and more to do with random disk read/write errors.
Have you tried replacing the HD cable? You never mentioned it.
Certainly for P-ATA disks, don't expect much in the way of error
detection unless Ultra DMA mode is being used (and even then, CRC error
checking is only performed for data packets, not for command and status
packets). It's unlikely to be a problem for S-ATA disks though.
--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Chronic MD5 Verification Errors
On 13/12/06 14:28, Edward Dam wrote:
Hi Ian,
Thanks for the help.
I've only got the main.cvd and daily.cvd databases in use right now,
until I
get this sorted out - so it's not a 3rd party db or script issue.
Here's basically what happens.
Freshclam downloads the updates, then notifes clamd to re-read the
databases. Then my log looks like this:
Wed Dec 13 06:05:04 2006 -> SelfCheck: Database status OK.
Wed Dec 13 06:28:57 2006 -> Reading databases from /var/clamav
Wed Dec 13 06:28:57 2006 -> ERROR: reload db failed: MD5 verification error
At this point mail is dead, and I have to delete the CVD files in
/var/clamav and re-run freshclam to get new ones, then manually start
clamav. All is well, until it happens again.
The frustrating part is that it's so intermittent. It doesn't happen every
time. It doesn't happen at a regular interval. It's completely random, with
the exception that it will probably once a day - or once every 2nd day on
the very high end.
What normally happens during the self-check is that the database
directory entries are read, but the files in the database directory are
not reloaded unless the directory entries have changed. This means that
the "SelfCheck: Database status OK." message does not mean the database
files were read okay, rather they weren't read at all.
May I suggest a minor code change for diagnostic purposes? In
clamd/server-th.c, look for the lines:
logg("SelfCheck: Database status OK.\n");
return NULL;
and change them to:
#if 0 /* original */
logg("SelfCheck: Database status OK.\n");
return NULL;
#else /* temporary test */
logg("SelfCheck: Database status OK. Reloading anyway.\n");
return root;
#endif
This will force the self-check to reload the database files even if
nothing has changed. Then if you get MD5 errors randomly after this
message in the logs, you'll know it has nothing to do with freshclam,
and more to do with random disk read/write errors.
Have you tried replacing the HD cable? You never mentioned it.
Certainly for P-ATA disks, don't expect much in the way of error
detection unless Ultra DMA mode is being used (and even then, CRC error
checking is only performed for data packets, not for command and status
packets). It's unlikely to be a problem for S-ATA disks though.
--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
Ian Abbott wrote the following on 12/13/2006 2:42 AM -0800: On 12/12/2006 19:44, Edward Dam wrote: Just to expand on this thought a bit. Shouldn't something like this be the default behaviour? To download the CVD files to a temp location, and run the MD5 there before moving it into the live database directory? This way a corrupt/bad database could be prevented from going live, and hanging the mail system. Only verified good cvd files would be moved into the live data dir, and clam would never hang because of this failure. freshclam already downloads cvd files using a temporary name and verifies them before installing them. cdiff files on the other hand are only verified if freshclam was built to use the GNU GMP library, and cdiff updates are applied to the live incremental databases. If anything goes wrong, the incremental database is removed and the full database downloaded. The thing I'm not too sure about is what happens if clamd is told to reload the databases while freshclam is in the middle of updating them (for example, from a script that updates the third party databases from MSRBL and SaneSecurity). I think it would be possible for clamd to see the databases in an inconsistent state in that case and crap out. Conversely, freshclam could tell clamd to reload the databases while some third party database update script is updating the third party databases. But in that case it is possible to write the third party database script so that each database is replaced atomically at the file system level (by ensuring that the old database and (a copy of) the new database are on the same filesystem before the atomically moving the new one over the old one). To avoid these problems, freshclam and the third party update scripts could be run sequentially from a single cron job, rather than running freshclam as a daemon. This is exactly what I do. Via cron.hourly (rather than freshclam daemon) I check for new files, if new then download and test the any new SaneSecurity and MSRBL signature files, then run freshclam. Work well here. Bill ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
Edward Dam wrote: Thanks for the pointer. It's similar, but not quite the same, in that the problems I have are with the main and daily cvd files. I am not a scripter by any stretch of the imagination, but.. Is there someway I could do the same with main.cvd and daily.cvd? What I mean is, would it be possible to modify freshclam so that when databases are downloaded, it puts them in a tmp dir, runs the MD5 check, and if it fails, NOT move them into the database directory, not notify CLAMD and deletes the files? Basically what I want to do is check to see if there are new databases if so, download to /tmp/clamtmp (for example) MD5 verify the new download in /tmp/clamtmp If good, move into the proper database dir and notify clamd (default behaviour for me). If bad, do nothing but delete the corrupt cvd. This process would then repeat itself the next time freshclam runs. This way I could ensure only GOOD .cvd files get set up, and clamav won't die on me regularly Thanks for the help... I got the same error, except Freshclam retried... main.cvd is up to date (version: 41, sigs: 73809, f-level: 10, builder: tkojm) nonblock_recv: recv timing out (30 secs) ERROR: Verification: MD5 verification error Trying again in 5 secs... ClamAV update process started at Wed Dec 13 10:51:38 2006 main.cvd is up to date (version: 41, sigs: 73809, f-level: 10, builder: tkojm) WARNING: Mirror 206.154.202.213 is not synchronized. Trying again in 5 secs... ClamAV update process started at Wed Dec 13 10:53:22 2006 main.cvd is up to date (version: 41, sigs: 73809, f-level: 10, builder: tkojm) daily.cvd updated (version: 2322, sigs: 7173, f-level: 9, builder: ccordes) Database updated (80982 signatures) from db.us.clamav.net (IP: 208.67.80.27) Clamd successfully notified about the update. Does your's try again? -- Thanks, James ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
Hi Ian, Thanks for the help. I've only got the main.cvd and daily.cvd databases in use right now, until I get this sorted out - so it's not a 3rd party db or script issue. Here's basically what happens. Freshclam downloads the updates, then notifes clamd to re-read the databases. Then my log looks like this: Wed Dec 13 06:05:04 2006 -> SelfCheck: Database status OK. Wed Dec 13 06:28:57 2006 -> Reading databases from /var/clamav Wed Dec 13 06:28:57 2006 -> ERROR: reload db failed: MD5 verification error At this point mail is dead, and I have to delete the CVD files in /var/clamav and re-run freshclam to get new ones, then manually start clamav. All is well, until it happens again. The frustrating part is that it's so intermittent. It doesn't happen every time. It doesn't happen at a regular interval. It's completely random, with the exception that it will probably once a day - or once every 2nd day on the very high end. On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote: On 12/12/2006 19:44, Edward Dam wrote: > Just to expand on this thought a bit. > > Shouldn't something like this be the default behaviour? To download the CVD > files to a temp location, and run the MD5 there before moving it into the > live database directory? > > This way a corrupt/bad database could be prevented from going live, and > hanging the mail system. Only verified good cvd files would be moved into > the live data dir, and clam would never hang because of this failure. freshclam already downloads cvd files using a temporary name and verifies them before installing them. cdiff files on the other hand are only verified if freshclam was built to use the GNU GMP library, and cdiff updates are applied to the live incremental databases. If anything goes wrong, the incremental database is removed and the full database downloaded. The thing I'm not too sure about is what happens if clamd is told to reload the databases while freshclam is in the middle of updating them (for example, from a script that updates the third party databases from MSRBL and SaneSecurity). I think it would be possible for clamd to see the databases in an inconsistent state in that case and crap out. Conversely, freshclam could tell clamd to reload the databases while some third party database update script is updating the third party databases. But in that case it is possible to write the third party database script so that each database is replaced atomically at the file system level (by ensuring that the old database and (a copy of) the new database are on the same filesystem before the atomically moving the new one over the old one). To avoid these problems, freshclam and the third party update scripts could be run sequentially from a single cron job, rather than running freshclam as a daemon. -- -=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
Thanks again for the replies. Disc I/0 and access are trouble free. They also have a samba file share on this server and it shows no errors with read/writes either (both are on the same RAID5 array). The only errors in any of the logs I can find (maillog, messages, clamd, freshclam, dmesg, etc) are these MD5 sum errors from clamav. The server has dual P4 Xeon 2.0 cpus, and 2 GB RAM. Load virtually never goes up over .50, except at night when the backups run (but no one is on and traffic is minimal) I did run the verbose freshclam logs for a time, but it gave me no useful information. I've just now turned it back on again, As for kernel, I'll give you the synopsis of how it went. Redhat 9.0 comes with a default kernel based on 2.4.20. This is the kernel the server was running until the mail server and backup were installed. Due to issues with the backup system, the kernel was upgraded to 2.4.31, Note: these clamav errors were happening under 2.4.20 already, although not nearly as frequently. After the upgrade to 2.4.31, the errors seem to have lessened (but not gone away.. maybe once a week instead of daily). Recently the errors were getting far more frequent (almost daily) so in an effort to resolve them, I upgraded to 2.4.33-4. Both 2.4.31 and 2.4.33-4 were compiled from vanilla sources, with the same config. Now, are there any special kernel options I should have enabled for clamav/freshclam that I can look into? Before upgrading to 2.4.33-4 I did a google search for that info, but came up with nil. Needless to say, the upgrade to 2.4.33-4 did nothing to correct the problem. Currently I've set the cron job for freshclam to only run once a day, to keep this from bringing the server down middday. Obviously this isn't a viable long term solution, but at least it will keep us running. I will try some of your suggestions below, but as you stated - I want to know *exactly* where the problem lies, and resolve it. On 12/13/06, G.W. Haywood < [EMAIL PROTECTED]> wrote: Hi there, On Tue-Wed, 12-13 Dec 2006 Edward Dam wrote: > > > Intermittently, freshclam would die with an MD5 verification error > > > > Does this very recent thread help at all? > > Error (Cannot connect to 'localhost:3310': IO::Socket::INET: connect:... > > It's similar, but not quite the same, in that the problems I have are with > the main and daily cvd files. I am not a scripter... > Is there someway I could do the same with main.cvd and daily.cvd? Yes. But if you haven't already done it, first of all I would suggest that you enable LogVerbose in your freshclam.conf to see if that sheds any light on the problem. Also have a look around in your system logs, especially for things like bad disc accesses. (NB: I haven't tested the following armchair theories. :) If things didn't become clearer, I'd probably run another freshclam (perhaps from cron) which maintains a separate copy of the problem databases. These copies are simply files for your delight and aren't used by the scanner. This might help to eliminate conflicts with processes actually using the databases for scanning. Log verbosely for both real and copy databases, and inspect the logs carefully. If the copies don't suffer from the same problems, then the simplest thing might be to do something like this in the same cron job: /bin/rm -rf/var/lib/clamav_old/ /bin/mv /var/lib/clamav/ /var/lib/clamav_old/ /bin/mv /var/lib/clamav_copy/ /var/lib/clamav/ /bin/mkdir /var/lib/clamav_copy/ This moves all the files at the same instant. Any process which has files in /var/lib/clamav/ open at the time of the move will still have the same files open but they will then be in /var/lib/clamav_old. To get the processes to use the new files you have to either restart them or send them the appropriate signal. Don't forget that you'll need a full set of the files in the copy database, not just the ones you're having problems with, or the procedure will fail. You can be creative and only do the operations above if a test in a cron job or script succeeds. See the earlier thread for examples or look at a shell scripting tutorial. It's easy. Don't overlook the "OnUpdateExecute" and "OnErrorExecute" options in the config file. Of course the copy databases might suffer from the same problem, in which case I guess we'll be hearing from you again. And of course the simplest thing might not be the best thing. I think I'd want to know exactly what the problem is, and fix it. :) I agree from your description of other software that hardware is probably not to blame, but the fact that the problem has become worse is suspicious. Would it be silly to ask if you've checked that you're not running into swap? Tried adding some more ram? Did the deterioration coincide with something like installing your new kernel? -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.c
[Clamav-users] Re: Chronic MD5 Verification Errors
Hi there, On Tue-Wed, 12-13 Dec 2006 Edward Dam wrote: > > > Intermittently, freshclam would die with an MD5 verification error > > > > Does this very recent thread help at all? > > Error (Cannot connect to 'localhost:3310': IO::Socket::INET: connect:... > > It's similar, but not quite the same, in that the problems I have are with > the main and daily cvd files. I am not a scripter... > Is there someway I could do the same with main.cvd and daily.cvd? Yes. But if you haven't already done it, first of all I would suggest that you enable LogVerbose in your freshclam.conf to see if that sheds any light on the problem. Also have a look around in your system logs, especially for things like bad disc accesses. (NB: I haven't tested the following armchair theories. :) If things didn't become clearer, I'd probably run another freshclam (perhaps from cron) which maintains a separate copy of the problem databases. These copies are simply files for your delight and aren't used by the scanner. This might help to eliminate conflicts with processes actually using the databases for scanning. Log verbosely for both real and copy databases, and inspect the logs carefully. If the copies don't suffer from the same problems, then the simplest thing might be to do something like this in the same cron job: /bin/rm -rf/var/lib/clamav_old/ /bin/mv /var/lib/clamav/ /var/lib/clamav_old/ /bin/mv /var/lib/clamav_copy/ /var/lib/clamav/ /bin/mkdir /var/lib/clamav_copy/ This moves all the files at the same instant. Any process which has files in /var/lib/clamav/ open at the time of the move will still have the same files open but they will then be in /var/lib/clamav_old. To get the processes to use the new files you have to either restart them or send them the appropriate signal. Don't forget that you'll need a full set of the files in the copy database, not just the ones you're having problems with, or the procedure will fail. You can be creative and only do the operations above if a test in a cron job or script succeeds. See the earlier thread for examples or look at a shell scripting tutorial. It's easy. Don't overlook the "OnUpdateExecute" and "OnErrorExecute" options in the config file. Of course the copy databases might suffer from the same problem, in which case I guess we'll be hearing from you again. And of course the simplest thing might not be the best thing. I think I'd want to know exactly what the problem is, and fix it. :) I agree from your description of other software that hardware is probably not to blame, but the fact that the problem has become worse is suspicious. Would it be silly to ask if you've checked that you're not running into swap? Tried adding some more ram? Did the deterioration coincide with something like installing your new kernel? -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Chronic MD5 Verification Errors
On 12/12/2006 19:44, Edward Dam wrote: Just to expand on this thought a bit. Shouldn't something like this be the default behaviour? To download the CVD files to a temp location, and run the MD5 there before moving it into the live database directory? This way a corrupt/bad database could be prevented from going live, and hanging the mail system. Only verified good cvd files would be moved into the live data dir, and clam would never hang because of this failure. freshclam already downloads cvd files using a temporary name and verifies them before installing them. cdiff files on the other hand are only verified if freshclam was built to use the GNU GMP library, and cdiff updates are applied to the live incremental databases. If anything goes wrong, the incremental database is removed and the full database downloaded. The thing I'm not too sure about is what happens if clamd is told to reload the databases while freshclam is in the middle of updating them (for example, from a script that updates the third party databases from MSRBL and SaneSecurity). I think it would be possible for clamd to see the databases in an inconsistent state in that case and crap out. Conversely, freshclam could tell clamd to reload the databases while some third party database update script is updating the third party databases. But in that case it is possible to write the third party database script so that each database is replaced atomically at the file system level (by ensuring that the old database and (a copy of) the new database are on the same filesystem before the atomically moving the new one over the old one). To avoid these problems, freshclam and the third party update scripts could be run sequentially from a single cron job, rather than running freshclam as a daemon. -- -=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
Just to expand on this thought a bit. Shouldn't something like this be the default behaviour? To download the CVD files to a temp location, and run the MD5 there before moving it into the live database directory? This way a corrupt/bad database could be prevented from going live, and hanging the mail system. Only verified good cvd files would be moved into the live data dir, and clam would never hang because of this failure. On 12/12/06, Edward Dam <[EMAIL PROTECTED]> wrote: Thanks for the pointer. It's similar, but not quite the same, in that the problems I have are with the main and daily cvd files. I am not a scripter by any stretch of the imagination, but.. Is there someway I could do the same with main.cvd and daily.cvd? What I mean is, would it be possible to modify freshclam so that when databases are downloaded, it puts them in a tmp dir, runs the MD5 check, and if it fails, NOT move them into the database directory, not notify CLAMD and deletes the files? Basically what I want to do is check to see if there are new databases if so, download to /tmp/clamtmp (for example) MD5 verify the new download in /tmp/clamtmp If good, move into the proper database dir and notify clamd (default behaviour for me). If bad, do nothing but delete the corrupt cvd. This process would then repeat itself the next time freshclam runs. This way I could ensure only GOOD .cvd files get set up, and clamav won't die on me regularly Thanks for the help... On 12/12/06, G.W. Haywood <[EMAIL PROTECTED]> wrote: > > Hi there, > > On Tue, 12 Dec 2006 Edward Dam wrote: > > > Intermittently, freshclam would die with an MD5 verification error > > Does this very recent thread help at all? > > Error (Cannot connect to 'localhost:3310': IO::Socket::INET: connect: > Connection refused ) > > -- > > 73, > Ged. > ___ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://lurker.clamav.net/list/clamav-users.html > ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
Thanks for the pointer. It's similar, but not quite the same, in that the problems I have are with the main and daily cvd files. I am not a scripter by any stretch of the imagination, but.. Is there someway I could do the same with main.cvd and daily.cvd? What I mean is, would it be possible to modify freshclam so that when databases are downloaded, it puts them in a tmp dir, runs the MD5 check, and if it fails, NOT move them into the database directory, not notify CLAMD and deletes the files? Basically what I want to do is check to see if there are new databases if so, download to /tmp/clamtmp (for example) MD5 verify the new download in /tmp/clamtmp If good, move into the proper database dir and notify clamd (default behaviour for me). If bad, do nothing but delete the corrupt cvd. This process would then repeat itself the next time freshclam runs. This way I could ensure only GOOD .cvd files get set up, and clamav won't die on me regularly Thanks for the help... On 12/12/06, G.W. Haywood <[EMAIL PROTECTED]> wrote: Hi there, On Tue, 12 Dec 2006 Edward Dam wrote: > Intermittently, freshclam would die with an MD5 verification error Does this very recent thread help at all? Error (Cannot connect to 'localhost:3310': IO::Socket::INET: connect: Connection refused ) -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Chronic MD5 Verification Errors
Hi there, On Tue, 12 Dec 2006 Edward Dam wrote: > Intermittently, freshclam would die with an MD5 verification error Does this very recent thread help at all? Error (Cannot connect to 'localhost:3310': IO::Socket::INET: connect: Connection refused ) -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
