Chuck Swiger wrote:
Bill Landry wrote:
[ ... ]
You are preaching to the choir here, as you have no argument from me. I
raised the same issue the last time this happened to me a few weeks ago
and clamd died twice on me in one day. The script work-around to check
the databases before implementing them has saved my bacon with this last
string of corrupted databases from MSRBL. However, I still agree that
clamd should be able to handle these kinds of issues gracefully, and in
the alternative, should not simply die silently.
Agreed-- it would be nice if clamd was more robust, either by continuing
to run with the other DBs (as available) and either drop the bad line or
the entire bad DB file, until a new update comes along which is OK.
However, improving how clamd responds to a bad DB is solving a
consequence or symptom rather than the original problem. Maybe we
should try to persuade the MSRBL site (and others) to use a similar
checking script when pushing new versions of the DB's out, rather than
checking upon receipt after people have used bandwidth to download and
then have to discard a bad update...?
Not really. Its about the same as going to a doctor and saying "hey
doc, it hurts when i go like this" and he responds with "well, dont do
that". Just as this is not a real solution, telling all DB creators to
make sure their files are ok or clamd will die is not a solution. This
isnt to say that these maintainers should not check the integrity of the
files they produce - they indeed should - but the real solution is that
clamd should not fail when it encounters a bad database file. This is
the only true way to avoid problems in this case.
-Jim
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
