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 evaluati
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 hi
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 m
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).
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 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 72_active.cf.
Mark
> 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 g
that's CPU-bound, no system calls => regexp matching. body, rawbody
or full rules.
On Thu, Mar 18, 2010 at 22:16, Matt Garretson
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 coincdence, or could
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 tw
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 thes
On Thu, Mar 18, 2010 at 21:56, 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
>> more):
>>
>> http://pastebin.com/2ssy2YEk
>
>
> Interesting. I see the same thing as you on that message. There's a
> two-m
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
13 matches
Mail list logo
