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 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
they want to do away with this system and put in an "industry standard" MS
Exchange system. If I don't stop the email downtime now, then I will have to
deal with an Exchange server, which is something I don't want..
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.
Ed
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
