[SOLVED] Clamav problem ? What's happening ?

[kuba]

I can confirm that changing the interval to 180 fixes things. It takes approx 100 seconds on my PE2650 (2xXeon 2.4GHz) server for clamd to start up. If it doesn't start up in the interval specified in zmmtaconfig, it will get re-started again and again.

I didn't upgrade zimbra's clamav to a newer version or anything. This is a RHEL4 system, and I do have a regular clamav rpm installed, and I could use that instead. Rather, I just opted for redhat's package to start up freshclam and not clamd, as there is a local copy of havp/squid combo to virus-filter the web traffic (this is our mail/squid server).

I presume it wouldn't be such a big deal to have zimbra just use the distribution-provided clamd, but there's just no need -- havp uses libclam only and there's no need for redhat's clamd running, only zimbra's and it works. Slow startup, but works nevertheless.

[rernst]

Originally Posted by kuba

I can confirm that changing the interval to 180 fixes things. It takes approx 100 seconds on my PE2650 (2xXeon 2.4GHz) server for clamd to start up. If it doesn't start up in the interval specified in zmmtaconfig, it will get re-started again and again.

I didn't upgrade zimbra's clamav to a newer version or anything. This is a RHEL4 system, and I do have a regular clamav rpm installed, and I could use that instead. Rather, I just opted for redhat's package to start up freshclam and not clamd, as there is a local copy of havp/squid combo to virus-filter the web traffic (this is our mail/squid server).

I presume it wouldn't be such a big deal to have zimbra just use the distribution-provided clamd, but there's just no need -- havp uses libclam only and there's no need for redhat's clamd running, only zimbra's and it works. Slow startup, but works nevertheless.

Just wanted to add my affirmation here that my AMD Sempron (don't even know the speed but plenty fast as a Zimbra server) takes slightly over 2 minutes to load the database. I saw that the interval had already been increased to 120 seconds but apparently the 180 seconds mentioned here are the magic number.

[aNt1X]

happy to see i'm not alone, and that my trick works

btw, i thought that i had to upgrade my Celeron Coppermine 733Mhz, but i see that even a 2xXeon 2.4GHz takes so long to load the db

see ya!

[cglusky]

Thank you very much for this post. Was having the same problem on OS X running a Dual 1GHz G4 w/ 1.5GB RAM. Once I increased interval I deleted contents of clam log (it was filled with restarts) and it works fine.

Thanks Again!
C

[JoshuaPrismon]

Originally Posted by aNt1X

Ok, i solved modifying the watchdog interval in /opt/zimbra/libexec/zmmtaconfig

[code]
my %config = (
progname => "zmmtaconfig",
hostname => $ENV{zimbra_server_hostname},
loglevel => 3,
watchdog => 1,
wd_all => 0,
debug => 0,
interval => 180,
baseDir => "/opt/zimbra",
logStatus => ( 4 => "Debug", 3 => "Info", 2 => "Warning", 1 => "Error", 0 =$
);[code]

(i extended the interval value from 60 to 180).

I was going crazy looking at crontabs, but this watchdog process wasn't in the crontab, but in this perl script

I hope it will not break something else ...

Thank you anyway.

aNt1X

As a quick note, this started occurring to me. For some reason the anti virus was taking far too long to come up and I had to modify this value to get the process to come up correctly.

[andydread]

Not sure if this helps but we are having the same problem with 4.5.5 OS
running on Ubuntu 6 on a 4core 2S Opteron server with 6GB ram. I would think this machine should be decent enough to load the database under 2 minutes but not sure why it takes so long to load.

Output of top with zimbra running properly (50 users)

Tasks: 202 total, 1 running, 201 sleeping, 0 stopped, 0 zombie
Cpu0 : 4.7% us, 3.3% sy, 0.0% ni, 88.0% id, 4.0% wa, 0.0% hi, 0.0% si
Cpu1 : 4.7% us, 2.3% sy, 0.0% ni, 93.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu2 : 2.0% us, 2.7% sy, 0.0% ni, 95.3% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 3.7% us, 2.3% sy, 0.0% ni, 94.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 6233236k total, 5137252k used, 1095984k free, 237728k buffers
Swap: 6225912k total, 172k used, 6225740k free, 3334916k cached


Output from /proc/cpuinfo ( CPU 3 - 4th CPU)

processor : 3
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 2210
stepping : 2
cpu MHz : 1800.174
cache size : 1024 KB
physical id : 1
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy
bogomips : 3600.14

[phoenix]

Originally Posted by andydread

Not sure if this helps but we are having the same problem with 4.5.5 OS

Have you made the changes outlined in the post above?

[mmorse]

4.5.7 will have a fix for this/a newer clamav version.
If your having trouble in the mean time, modify the watchdog timeout or attempt to update clamav.

[andydread]

Yep I changed the timeout from 60 - 180
it seems to be working now. Just was wondering why it needs that long to
start the database on this particular beast. I suspect its clamav issue in and
of itself. Found others running into similar issues running clamav without
zimbra at all. Hopefully the new version that comes with 4.5.7 when it comes
out will be faster at loading the database too.

[jholder]

Originally Posted by andydread

Yep I changed the timeout from 60 - 180
it seems to be working now. Just was wondering why it needs that long to
start the database on this particular beast. I suspect its clamav issue in and
of itself. Found others running into similar issues running clamav without
zimbra at all. Hopefully the new version that comes with 4.5.7 when it comes
out will be faster at loading the database too.

Yeah, it left us scratching our heads as well. We didn't exactly *patch* this. We just upgraded clamav, and it seemed to go away. We're hoping it was an issue with the version of clamd that we bundled.

::crossing our fingers::