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
