John Hardin, 2010-03-21 01:01:
The offending rule is FILL_THIS_FORM_LONG from 72_active.cf.
I'll look into it.
Fix is in local masscheck testing.
Fix committed.
But not online yet? At least not with 3.3.1's sa-update, it still takes
nearly 5 minutes to scan this message (last hit is
On Monday March 22 2010 11:49:22 Jakob Hirsch wrote:
Btw, shouldn't --timeout-child on spamd limit the time spent?
I have set it to 30, but that does not seem to work.
The signal handling in 3.3 is left at perl default of
'safe handling', which means that alarm signal cannot
interrupt
On Thu, 18 Mar 2010, John Hardin wrote:
On Thu, 18 Mar 2010, John Hardin wrote:
On Fri, 19 Mar 2010, Mark Martinec wrote:
The offending rule is FILL_THIS_FORM_LONG from 72_active.cf.
I'll look into it.
Fix is in local masscheck testing.
Fix committed.
--
John Hardin KA7OHZ
Gary Smith wrote:
I'm not seeing your 130 sec CPU issue on my end. Are as mentioned by Matt, are
you running into some DNS issue? These are stock rule + other house rules in
place. I'm not getting any type of DNS hit, this might because you modified
the headers. Either way, 5 seconds for
Every so often I get nudged to check into a message stuck on one of our
inbound MXes.
So far, every one of them has been spam, but a few have cause some odd
behaviour with spamc/spamd.
Here's one pretty much guaranteed to peg a CPU core for ~130 seconds (or
more):
On 3/18/2010 5:15 PM, Kris Deugau wrote:
Here's one pretty much guaranteed to peg a CPU core for ~130 seconds (or
more):
http://pastebin.com/2ssy2YEk
Interesting. I see the same thing as you on that message. There's a
two-minute gap between these two debug lines:
rules: ran body rule
On Thu, Mar 18, 2010 at 21:56, Matt Garretson
ma...@assembly.state.ny.us wrote:
On 3/18/2010 5:15 PM, Kris Deugau wrote:
Here's one pretty much guaranteed to peg a CPU core for ~130 seconds (or
more):
http://pastebin.com/2ssy2YEk
Interesting. I see the same thing as you on that message.
On 3/18/2010 5:56 PM, Matt Garretson wrote:
On 3/18/2010 5:15 PM, Kris Deugau wrote:
Here's one pretty much guaranteed to peg a CPU core for ~130 seconds (or
http://pastebin.com/2ssy2YEk
Interesting. I see the same thing as you on that message. There's a
two-minute gap between these two
On 3/18/2010 6:06 PM, Matt Garretson wrote:
It looks like a dns call (or two?) for URI-A took 120 seconds to return.
Is that a mere coincdence, or could that be causing a spin of some sort?
FWIW, strace shows spamassassin doing this about twice a second
(with varying arguments) during the
that's CPU-bound, no system calls = regexp matching. body, rawbody
or full rules.
On Thu, Mar 18, 2010 at 22:16, Matt Garretson
ma...@assembly.state.ny.us wrote:
On 3/18/2010 6:06 PM, Matt Garretson wrote:
It looks like a dns call (or two?) for URI-A took 120 seconds to return.
Is that a mere
Here's one pretty much guaranteed to peg a CPU core for ~130 seconds (or
more):
http://pastebin.com/2ssy2YEk
I'm not seeing your 130 sec CPU issue on my end. Are as mentioned by Matt, are
you running into some DNS issue? These are stock rule + other house rules in
place. I'm not
On Fri, 19 Mar 2010, Mark Martinec wrote:
On Thursday March 18 2010 23:18:56 Justin Mason wrote:
that's CPU-bound, no system calls = regexp matching. body, rawbody
or full rules.
Yes, it's terrible, takes 4 minutes here (SA 3.3, perl 5.10.1).
The offending rule is FILL_THIS_FORM_LONG from
On Thu, 18 Mar 2010, John Hardin wrote:
On Fri, 19 Mar 2010, Mark Martinec wrote:
On Thursday March 18 2010 23:18:56 Justin Mason wrote:
that's CPU-bound, no system calls = regexp matching. body, rawbody
or full rules.
Yes, it's terrible, takes 4 minutes here (SA 3.3, perl 5.10.1).
13 matches
Mail list logo
