[Clamav-announce] announcing ClamAV 0.93.2

Meesterlijk

Verified User
Joined
Jan 19, 2007
Messages
179
Location
Netherlands
Dear ClamAV users,

This release fixes and re-enables the Petite unpacker, improves database
loading and solves some other minor issues.


--
The ClamAV team (http://www.clamav.net/team)

--
Luca Gibelli (luca _at_ clamav.net) ClamAV, a GPL anti-virus toolkit
[Tel] +39 0187 1851862 [Fax] +39 0187 1852252 [IM] nervous/jabber.linux.it
PGP key id 5EFC5582 @ any key-server || http://www.clamav.net/gpg/luca.gpg
 
I don't know what happened, but the latest is 0.93.3 now.

I'm updated and working perfectly :)
 
I have updated clamav a few hours ago, and since the update clamd dies every 20 minutes or so. It is extremely frustrating.

I am running CentOS 5.2, and clamd reports:

[root@server1 clamav]# clamd --version
ClamAV 0.93.2/7680/Wed Jul 9 18:31:16 2008
[root@server1 clamav]#


Yum update does not find any new versions. Has anybody had this problem?
 
Since yum was not reporting a newer version than 0.93.2, I downloaded and manually compiled/installed 0.93.3. It died once last night, but definitely isn't nearly as bad as .2 was. I'm still not happy that it died though.

We will see how it acts throughout the day today.
 
Well, it seems to be doing it about every 4 hours now instead of every 20 minutes.

Googling does nothing for me. Does anyone have any idea why the process would just randomly die without any sort of panic information in any log files?
 
0.93.2 is a shocker for me too. Dies every 30 minutes or so. I was going to compile 0.93.3, but if it's still having issues, I will stick to my cron job restarting it every 20 minutes!
 
Actually, should share what I do in case anyone is not doing it.

Check out clamdwatch, it's in the contrib directory of the clamav source.

A few tweaks for whatever distro your running, and you have your self a perfect clamd watchdog.

I run it every minute with cron, if it detects that clamd is down, it restarts it.

It's an essential to run even if your not having this problem really.
 
Yep, I use the same thing. It's just frustrating that it even has to restart it to begin with.

So far it has been 7 hours and no crash yet. I turned verbose logging, and logging of clean emails on to try to get the exact last thing it did before it crashes.
 
I might turn the logging on too to try pin that one down.

Ours seems to die almost religiously every 30 minutes . I have another box running the same build that does not crash at all. But it's not an email server so it's not got any load on it, so its probably not relevant. The problem one is on a 64bit Centos install though, whereas the one that's not failing is 32bit. Could be a factor.
 
I might turn the logging on too to try pin that one down.

Ours seems to die almost religiously every 30 minutes . I have another box running the same build that does not crash at all. But it's not an email server so it's not got any load on it, so its probably not relevant. The problem one is on a 64bit Centos install though, whereas the one that's not failing is 32bit. Could be a factor.

My CentOS is also 64 bit. The process hasn't crashed since turning verbose and clean email logging on, but it sure does suck up a ton more RAM than it usually does. The process was up to 230 megs of ram usage before I rebooted it and it went back down to 117. That is a ridiculous amount
 
Does anybody know of any free antivirus mail gateway software that would replace clamav/clamd? I cannot for the life of me find anything. Is ClamAV really *it*?
 
Does anybody know of any free antivirus mail gateway software that would replace clamav/clamd? I cannot for the life of me find anything. Is ClamAV really *it*?

Yes I was having exactly the same thought! May years ago I was using a few different ones, I forget the names, but I think maybe Bit Defender may have been one of them?

I think I read somewhere that AVG has one too, in fact I think there is a howto on the forums somewhere for that one.

I'm actually looking into commercial options, but my research will probably result in the same conclusion as before, too big a price gap between free and paid for. If I'm going to fork out for commercial antivirus then I may as well just shift all filtering to a barracuda box or something.

Certainly want to do away with ClamAV though, I'm over it.
 
Okay I have tracked down the even causing clamd to fail.

I just changed it to run in the foreground, ran it from the console and waited for it to die, here's the error:

No stats for Database check - forcing reload
Reading databases from /var/clamav
/tmp/clamdwatch-JwjnjN4zj8WhYRx9: Eicar-Test-Signature FOUND
Segmentation fault

The clamdwatch line is the watchdog restarting it, so the segfault like may not be related, it could just be a side effect of cron trying to start clamd when it's set to run in the foreground.

But certainly this database check is related, I have seen it mentioned before but didn't pay any attention at the time. Not looked into this any further yet, but will do a little later on.
 
Okay, I may have a possible fix to this. The previous error I posted was useless, I didn't have verbose logging turned on. Turning on verbose logging gives:

Accepted connection on port 1855, fd 9
LibClamAV Error: cli_dbgets: Preliminary end of data
LibClamAV Error: cli_dbgets: Preliminary end of data
LibClamAV Error: Empty database file
LibClamAV Error: Can't load daily.ndb: Malformed database
LibClamAV Error: cli_tgzload: Invalid size in header
LibClamAV Error: Can't load /var/clamav/daily.cld: Malformed database
ERROR: reload db failed: Malformed database
Terminating because of a fatal error.

So if this is to be believed it's does not like the database. So I shutdown clamd, removed contents of /var/clamd then ran freshclam to get a fresh copy of the database.

Started up clamd again, and it's worked perfectly since.
 
Okay, I may have a possible fix to this. The previous error I posted was useless, I didn't have verbose logging turned on. Turning on verbose logging gives:

Accepted connection on port 1855, fd 9
LibClamAV Error: cli_dbgets: Preliminary end of data
LibClamAV Error: cli_dbgets: Preliminary end of data
LibClamAV Error: Empty database file
LibClamAV Error: Can't load daily.ndb: Malformed database
LibClamAV Error: cli_tgzload: Invalid size in header
LibClamAV Error: Can't load /var/clamav/daily.cld: Malformed database
ERROR: reload db failed: Malformed database
Terminating because of a fatal error.

So if this is to be believed it's does not like the database. So I shutdown clamd, removed contents of /var/clamd then ran freshclam to get a fresh copy of the database.

Started up clamd again, and it's worked perfectly since.

Good call! I had the problem where everytime the database was reloaded, clamd's memory doubled.

I did the same thing, and the memory usage went from 117M(normal)-230M(after automatic db reload), to 70M.

Hopefully it will stay at 70
 
Good call! I had the problem where everytime the database was reloaded, clamd's memory doubled.

I did the same thing, and the memory usage went from 117M(normal)-230M(after automatic db reload), to 70M.

Hopefully it will stay at 70

Yes I got the exact same results, now uses 71M. The daemon was dieing every 30 min, have had this fix on for 3 hours now with not a single failure, so for me it's certainly fixed it... yay :)
 
Ugh. Database automatically reloaded, ram doubled again. It's now at 134

That's no good :(

Mine just died too after a good 24 hours of stability. For the moment I may just modify the clamdwatch script to dump the database and run freshclam. Should solve the memory issues and require less restarts.
 
Back
Top