Tomasz Kojm wrote:
On Thu, 15 Feb 2007 13:51:54 -0800
Bill Landry <[EMAIL PROTECTED]> wrote:
I just had to back it out of production. It would not run more than a
couple minutes under a normal load that 88.7 shrugs off. It dies without
any error messages.
dp
Yep, I observed the same behavior on Fedora Core 3, where clamd 0.90
dies without any indication as to why in any log files. Not good...
You didn't provide _any_ information that could be useful to us for debugging
those issues.
I realize that and I apologize, but I've got a lot going on just now.
There's not a lot to say yet. Solaris 9 in a Sun E250 w/2g ram, 80,000
messages/day per instance, running with a milter (J-chkmail - beautiful
milter, Jose!) in Sendmail 8.14.0. It all works perfectly with 0.88.7
and every previous version. The configs were carefully updated with the
new conf file samples, all permissions/ownerships verified, a fresh
install of bzip2 was built just for this and it works great, too.
The clamd daemon starts up fine, a socket is created in /tmp, the milter
finds it, it rejects viruses for a couple minutes, then it dies. Not a
clue in any logs, no core file. Watching in top the size is expected,
the cpu bumps around 33% for clamd - expected numbers given the size of
our attachments. I need to rework my daemon watchdog because this
version of clamd is more sensitive to stale socket files and I need to
delete it before restarting - that's an aside, not part of the problem.
Regretably I have to set this aside until all the 2007USADST patches are
done, and getting downtime permission on systems is agonizing.
It is running fine in two other systems that have far fewer
connection/minute - like 2000 messages/day. No crashes on those systems
yet, and no hint of memory leaks.
Here is one thing I noted during testing - I ran clamdscan against the
contents of my /tmp directory which in Solaris is a RAM disk much of the
time. Maybe 30 files in there, nothing big, but also mostly text files.
It was noticibly slow and I hit ctrl-C to stop the clamdscan processes,
but it was a good 45 seconds before the cpu usage of clamd fell to idle
levels from 45% cpu usage (again, dual proc Sun E250). That seemed like
a long time to spin following a broken socket, but it may be that it
finishes out the last scan before yielding back resources.
dp
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
