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.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
