Hi Nigel-
On Aug 28, 2006, at 6:42 AM, Nigel Horne wrote:
Repeating advice already given here: the engine in 0.88 is *old*.
If performance is
an issue upgrade to the code in CVS.
Thanks for your response. We'll definitely look at doing that.
Just to confirm: you would expect clamd processe
Howdy-
We've recently been seeing our clamd processes run very hot (spiking
up to 85% of the CPU as reported by prtstat and top) on two different
Solaris 9 boxes. For example, here's a few lines from prtstat -L
(showing the two clamav threads who are together eating 66% of the
CPU) .
PI
Hi Jeremy-
If you run the message back through SA with the -d or
--remove-markup switch, it will undo its encapsulation of the spam
message.
-- dNb
___
http://lurker.clamav.net/list/clamav-users.html
On Mar 24, 2005, at 1:12 PM, Elizabeth Schwartz wrote:
This sounds like exactly what I was experiencing. Did the latest build
fix it for you? Turning off clamd and running clamav-milter without
the --external flag seems to have fixed it for me.
Hi Betsy-
See my followup message on March 17th, but
Howdy-
Now that > a week has gone by with absolutely no problems with our
clamd hanging, I thought I would write in to provide the good news that
I think we have this problem licked. Though we also rev'd exim on Wed,
I think it was the upgrade for 0.83 to devel-20050308 that solved our
probl
Howdy-
I just wanted to pop in and provide the latest update on our saga
(clamd 0.83 just stops playing nice after running for a while) with
some more interesting information like stack traces.
Last we left off I had just upped the ulimit for the clamd process from
the default of 256 fds to 102
On Feb 18, 2005, at 2:49 PM, Andy Fiddaman wrote:
The accept debug will at least tell us if you're running out of file
descriptors..
Roger.
# ndd /dev/tcp tcp_time_wait_interval
6
# pfiles `pgrep clamd` | grep rlimit
Current rlimit: 256 file descriptors
Current rlimit: 256 file descriptors
On Feb 18, 2005, at 4:12 AM, Trog wrote:
This really looks like you're running out of some resource. That accept
() failure is from the clamd primary socket. We will need to find out
what the error is. Please try this patch:
Hi Trog and Andy-
Thanks for your responses. I've just patched my sources
On Feb 18, 2005, at 3:04 AM, Fajar A. Nugraha wrote:
4.34? That's old. If I remember correctly, I had some problem with
that version as well.
Use (at least) exim 4.41. That's what I use here, and it runs fine.
Both Solaris 8 and 9.
Yes, the version of exim is a little behind (they rev'd through t
On Feb 18, 2005, at 2:24 AM, René Berber wrote:
Another idea: exiscan has some known problems, depending on the
version, for instance see the following thread:
http://www.gossamer-threads.com/lists/clamav/users/12973?nohighlight=1
Hmm, that's an interesting thought, though I'm running
exiscan
On Feb 18, 2005, at 1:40 AM, René Berber wrote:
Nobody is pointing the obvious, the Debug option is not for production
use, it could hang your clamd daemon under load.
Thanks for looking carefully at the config. This was turned on only
after I started having problems in the hopes it would provide
(sorry for the weird quoting format and the breaking of the threading,
I just switched myself back off digest mode so I don't have an easy way
to respond to single messages for another message or two)
From: James Lick <[EMAIL PROTECTED]>:
I'm running clamd 0.83 on Solaris 9 compiled with gcc 3.4
From: Igor Brezac <[EMAIL PROTECTED]>:
How much memory does your clamd process consume when it stops
running?
Hi Igor-
I haven't checked (the machine it is running on has plenty of memory
and swap), but I will check next time this happens. Would you be
willing to share your build configurati
Hi-
Thanks for such a great program and all of the work being put into
it. We're having a nasty problem with clamd 0.8x (even with 0.83 which
we just installed yesterday). After running for a while, it will decide
to just stop functioning and return failures or refuse connect from the
MTA. He
14 matches
Mail list logo
