You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Chris Conn <cc...@abacom.com> on 2018/04/18 14:00:17 UTC
plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Hello,
We recently started having problems on a few servers with spamd
processes starting to hog RAM (3G++ per child) and we are noting some
timeouts in the logs. as well, we are seeing this msg
Apr 18 08:48:24 spamd[2451]: plugin: eval failed: __alarm__ignore__(156)
Apr 18 08:58:25 spamd[11283]: plugin: eval failed: __alarm__ignore__(156)
Apr 18 09:05:28 spamd[17774]: plugin: eval failed: __alarm__ignore__(156)
Apr 18 09:09:06 spamd[21486]: plugin: eval failed: __alarm__ignore__(156)
Apr 18 09:11:56 spamd[23412]: plugin: eval failed: __alarm__ignore__(156)
Apr 18 09:13:50 spamd[24872]: plugin: eval failed: __alarm__ignore__(156)
Apr 18 09:14:11 spamd[25147]: plugin: eval failed: __alarm__ignore__(246)
Apr 18 09:19:37 spamd[29797]: plugin: eval failed: __alarm__ignore__(246)
Apr 18 09:28:54 spamd[5298]: plugin: eval failed: __alarm__ignore__(246)
Apr 18 09:40:00 spamd[13590]: plugin: eval failed: __alarm__ignore__(246)
Apr 18 09:40:28 spamd[13847]: plugin: eval failed: __alarm__ignore__(246)
Apr 18 09:41:21 spamd[14389]: plugin: eval failed: __alarm__ignore__(246)
Apr 18 09:50:45 spamd[24479]: plugin: eval failed: __alarm__ignore__(331)
This alarm__ignore seems to be a function in Timeout.pm
this is a relatively old install, SA 3.3.1 on Centos6 (stock RPMs)
Any tips on how to troubleshoot the essence or root of this issue?
Thanks in advance,
Chris
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Daniele Duca <du...@staff.spin.it>.
On 18/04/2018 16:08, David Jones wrote:
>
> I too have been seeing a very high number of SA timeouts via
> MailScanner the past week and would like to know how to troubleshoot
> these timeouts. I have never been able to catch problem messages in
> the act to figure out what is causing them.
>
FWIW, when I had intermittent timeouts some time ago
(TIME_LIMIT_EXCEEDED in my case, not sure if it's applicable here) and
after losing hours with the ruletiming plugin trying to understand what
was happening, it turned out to be a physical network problem between
the server where SA ran and the database where AWL and Bayes resided,
that resulted in random packet loss.
This is only to suggest to start from layer 1 before everything else :)
Good luck
Daniele Duca
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by David Jones <dj...@ena.com>.
On 04/18/2018 09:00 AM, Chris Conn wrote:
> Hello,
>
> We recently started having problems on a few servers with spamd
> processes starting to hog RAM (3G++ per child) and we are noting some
> timeouts in the logs. as well, we are seeing this msg
>
> Apr 18 08:48:24 spamd[2451]: plugin: eval failed: __alarm__ignore__(156)
> Apr 18 08:58:25 spamd[11283]: plugin: eval failed: __alarm__ignore__(156)
> Apr 18 09:05:28 spamd[17774]: plugin: eval failed: __alarm__ignore__(156)
> Apr 18 09:09:06 spamd[21486]: plugin: eval failed: __alarm__ignore__(156)
> Apr 18 09:11:56 spamd[23412]: plugin: eval failed: __alarm__ignore__(156)
> Apr 18 09:13:50 spamd[24872]: plugin: eval failed: __alarm__ignore__(156)
> Apr 18 09:14:11 spamd[25147]: plugin: eval failed: __alarm__ignore__(246)
> Apr 18 09:19:37 spamd[29797]: plugin: eval failed: __alarm__ignore__(246)
> Apr 18 09:28:54 spamd[5298]: plugin: eval failed: __alarm__ignore__(246)
> Apr 18 09:40:00 spamd[13590]: plugin: eval failed: __alarm__ignore__(246)
> Apr 18 09:40:28 spamd[13847]: plugin: eval failed: __alarm__ignore__(246)
> Apr 18 09:41:21 spamd[14389]: plugin: eval failed: __alarm__ignore__(246)
> Apr 18 09:50:45 spamd[24479]: plugin: eval failed: __alarm__ignore__(331)
>
> This alarm__ignore seems to be a function in Timeout.pm
>
> this is a relatively old install, SA 3.3.1 on Centos6 (stock RPMs)
>
> Any tips on how to troubleshoot the essence or root of this issue?
>
> Thanks in advance,
>
> Chris
I too have been seeing a very high number of SA timeouts via MailScanner
the past week and would like to know how to troubleshoot these timeouts.
I have never been able to catch problem messages in the act to figure
out what is causing them.
--
David Jones
Re: plugin: eval failed: __alarm__ignore__(xxx) how to
troubleshoot
Posted by John Hardin <jh...@impsec.org>.
On Fri, 20 Apr 2018, Bill Cole wrote:
> On 20 Apr 2018, at 14:50 (-0400), John Hardin wrote:
>
>> Given your findings, I kinda suspect *all* of the tflags=multiple rules are
>> misbehaving from time to time under 3.3.1 - the compiled code may be
>> getting into an infinite loop somehow if the number if *real* hits on the
>> rule exceeds some value - I note there were 17 hits on "your business"
>> there.
>
> Not ALL rules... Unless I'm addled by the past 2 days of fever, it looks like
> an example of this SA bug caused by a perl bug:
>
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6558
Good catch!
> I'm surprised RH didn't backport the fix for either perl or SA.
Indeed.
Decorating __GENERATE_LEADS with the bugfix check.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
[For Earth Day] Obama flew a 747 all the way to the Everglades
then rode in a massive SUV motorcade to tell you
to cut carbon emissions. -- Twitter satirist @hale_razor
-----------------------------------------------------------------------
2 days until Earth Day
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 20 Apr 2018, at 14:50 (-0400), John Hardin wrote:
> Given your findings, I kinda suspect *all* of the tflags=multiple
> rules are misbehaving from time to time under 3.3.1 - the compiled
> code may be getting into an infinite loop somehow if the number if
> *real* hits on the rule exceeds some value - I note there were 17 hits
> on "your business" there.
Not ALL rules... Unless I'm addled by the past 2 days of fever, it looks
like an example of this SA bug caused by a perl bug:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6558
I'm surprised RH didn't backport the fix for either perl or SA.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by "Kevin A. McGrail" <km...@apache.org>.
Pedro, ideas are great but patches are essential. If you are interested in
said feature, please consider submitting a patch to achieve it. Especially
because I can guarantee you that very few people will put any cycles on a
3.3.X release issue.
--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Sun, Apr 22, 2018 at 2:27 PM, Pedro David Marco <pe...@yahoo.com>
wrote:
>
>
> >Given your findings, I kinda suspect *all* of the tflags=multiple rules
> >are misbehaving from time to time under 3.3.1 - the compiled code may be
> >getting into an infinite loop somehow if the number if *real* hits on the
> >rule exceeds some value - I note there were 17 hits on "your business
>
> Maybe ths is a good moment to speak again about my old suggestion
> of having a kind of:
>
> tflags=multiple-uniq
>
> to avoid repeated values
>
> ------
> PedroD
>
>
> .
>
>
>
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Pedro David Marco <pe...@yahoo.com>.
>Given your findings, I kinda suspect *all* of the tflags=multiple rules
>are misbehaving from time to time under 3.3.1 - the compiled code may be
>getting into an infinite loop somehow if the number if *real* hits on the
>rule exceeds some value - I note there were 17 hits on "your business
Maybe ths is a good moment to speak again about my old suggestionof having a kind of:
tflags=multiple-uniq
to avoid repeated values
------PedroD
.
Re: plugin: eval failed: __alarm__ignore__(xxx) how to
troubleshoot
Posted by John Hardin <jh...@impsec.org>.
On Fri, 20 Apr 2018, Chris Conn wrote:
>
>> Yeah, because 3.4.x implements maxhits.
>>
>> So, should I disable the __GENERATE_LEADS family for < 3.4.0? I suspect it
>> would be prudent, but I am surprised the other tflags=multiple rules aren't
>> also problematic in the same manner...
>>
>>
>
> Hello,
>
> I don`t think I am in a position to comment on where to go from here for SA <
> 3.4.0 .
Ugh, I was unclear there. That was a general question directed at the list
members.
> I am just glad I found the cause and was able to find and share a
> workaround and findings to the mailing list.
Agreed, thanks!
> This is perhaps one of many loops, I would have to check other emails;
> however, over the last 2-3 weeks, we have noted that SA started to become a
> huge memory and cpu hog, with a growing number of timeouts in emails not
> completing within 300 seconds of scan and also occasionally servers running
> out of RAM; this could be coincidence, or new rules in the sa-update?
Given your findings, I kinda suspect *all* of the tflags=multiple rules
are misbehaving from time to time under 3.3.1 - the compiled code may be
getting into an infinite loop somehow if the number if *real* hits on the
rule exceeds some value - I note there were 17 hits on "your business"
there.
> In any case, here without Rule2XBody I am able to operate until I can
> get 3.4.x deployed.
Please let us know whether that improves your *overall* memory/cpu hogging
and timeout problems.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
[For Earth Day] Obama flew a 747 all the way to the Everglades
then rode in a massive SUV motorcade to tell you
to cut carbon emissions. -- Twitter satirist @hale_razor
-----------------------------------------------------------------------
2 days until Earth Day
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Chris Conn <cc...@abacom.com>.
> Yeah, because 3.4.x implements maxhits.
>
> So, should I disable the __GENERATE_LEADS family for < 3.4.0? I
> suspect it would be prudent, but I am surprised the other
> tflags=multiple rules aren't also problematic in the same manner...
>
>
Hello,
I don`t think I am in a position to comment on where to go from here for
SA < 3.4.0 . I am just glad I found the cause and was able to find and
share a workaround and findings to the mailing list.
This is perhaps one of many loops, I would have to check other emails;
however, over the last 2-3 weeks, we have noted that SA started to
become a huge memory and cpu hog, with a growing number of timeouts in
emails not completing within 300 seconds of scan and also occasionally
servers running out of RAM; this could be coincidence, or new rules in
the sa-update? In any case, here without Rule2XBody I am able to
operate until I can get 3.4.x deployed.
Thanks again,
Chris
Re: plugin: eval failed: __alarm__ignore__(xxx) how to
troubleshoot
Posted by John Hardin <jh...@impsec.org>.
On Fri, 20 Apr 2018, Chris Conn wrote:
>
>> WTF? If tflags=multiple is supported at all, it should behave properly
>> (i.e. not hitting over and over on the *same bit of text*).
>>
>> maxhits was implemented after 3.3.1; is it possible that there are just a
>> *lot* of instances of "your business" in that test message, and it's simply
>> hitting all of them?
>>
>> Can anyone else confirm this on 3.3.1? Run through a test message with
>> *one* instance of "your business" and get repeated hits on it in
>> __GENERATE_LEADS?
>>
>> While __GENERATE_LEADS is recent, there are a lot of tflags=multiple rules
>> in the base ruleset that have been there for a long time - I'd expect this
>> to have come up much earlier.
>>
>>> I tested on Centos7 with sa-update done and rules compiled, this rule does
>>> not trigger a loop.
>>
>> You tested 3.3.1 on C7? Or the native 3.4.0, which does implement maxhits?
>>
>> Are the SA 3.3.1 sources different between the C6 and C7 packages?
>
> Hello,
>
> To follow up; if I disable Rule2XSBody plugin (rule compilation), on Centos6
> SA 3.3.1-3 there is no loop;
Whew!
> however, with Rule2XSBody enabled, on SA 3.3.1 on Centos6, it loops forever.
Rats!
> With or witout Rule2XSBody on Centos7 SA 3.4.0-2 bundled SA rpm, it works
> correctly.
Yeah, because 3.4.x implements maxhits.
So, should I disable the __GENERATE_LEADS family for < 3.4.0? I suspect it
would be prudent, but I am surprised the other tflags=multiple rules
aren't also problematic in the same manner...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
[For Earth Day] Obama flew a 747 all the way to the Everglades
then rode in a massive SUV motorcade to tell you
to cut carbon emissions. -- Twitter satirist @hale_razor
-----------------------------------------------------------------------
2 days until Earth Day
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Chris Conn <cc...@abacom.com>.
> WTF? If tflags=multiple is supported at all, it should behave properly
> (i.e. not hitting over and over on the *same bit of text*).
>
> maxhits was implemented after 3.3.1; is it possible that there are
> just a *lot* of instances of "your business" in that test message, and
> it's simply hitting all of them?
>
> Can anyone else confirm this on 3.3.1? Run through a test message with
> *one* instance of "your business" and get repeated hits on it in
> __GENERATE_LEADS?
>
> While __GENERATE_LEADS is recent, there are a lot of tflags=multiple
> rules in the base ruleset that have been there for a long time - I'd
> expect this to have come up much earlier.
>
>> I tested on Centos7 with sa-update done and rules compiled, this rule
>> does not trigger a loop.
>
> You tested 3.3.1 on C7? Or the native 3.4.0, which does implement
> maxhits?
>
> Are the SA 3.3.1 sources different between the C6 and C7 packages?
Hello,
To follow up; if I disable Rule2XSBody plugin (rule compilation), on
Centos6 SA 3.3.1-3 there is no loop;
Apr 20 14:14:05.138 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "G"
Apr 20 14:14:05.138 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "A"
Apr 20 14:14:05.138 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "M"
Apr 20 14:14:05.139 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "W"
Apr 20 14:14:05.139 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "T"
Apr 20 14:14:05.139 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "G"
Apr 20 14:14:05.139 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "A"
Apr 20 14:14:05.139 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "I"
Apr 20 14:14:05.139 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "A"
Apr 20 14:14:05.139 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "I"
Apr 20 14:14:05.140 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "N"
Apr 20 14:14:05.140 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: "C"
Apr 20 14:14:05.140 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: " L"
Apr 20 14:14:05.140 [27778] dbg: rules: ran body rule __BODY_TEXT_LINE
======> got hit: " T"
Apr 20 14:14:05.789 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.790 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.790 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.791 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.791 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.792 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.792 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.793 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.796 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.797 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.797 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.798 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.798 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.799 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.799 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.799 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:05.799 [27778] dbg: rules: ran body rule __GENERATE_LEADS
======> got hit: "your business"
Apr 20 14:14:06.444 [27778] dbg: rules: ran body rule __HIGHBITS ======>
got hit: "â?¢ â?? "
Apr 20 14:14:06.590 [27778] dbg: rules: running uri tests; score so
far=4.9999
however, with Rule2XSBody enabled, on SA 3.3.1 on Centos6, it loops forever.
With or witout Rule2XSBody on Centos7 SA 3.4.0-2 bundled SA rpm, it
works correctly.
I am disabling Rule2XSBody for now while I rebuild Centos7 boxes.
Chris
Re: plugin: eval failed: __alarm__ignore__(xxx) how to
troubleshoot
Posted by John Hardin <jh...@impsec.org>.
On Fri, 20 Apr 2018, Chris Conn wrote:
> On 4/18/2018 10:32 AM, Benny Pedersen wrote:
>> Chris Conn skrev den 2018-04-18 16:00:
>>
>>> this is a relatively old install, SA 3.3.1 on Centos6 (stock RPMs)
>>
>> maybe solved in centos7 ?
>
> I believe I found the issue. On my Centos6 boxes with SA 3.3.1 (the
> maintained version by RedHat/CentOS), using sa-update rules, there is a loop;
>
> Apr 20 13:29:48.636 [18363] dbg: rules: ran one_line_body rule
> __GENERATE_LEADS ======> got hit: "your business"
> Apr 20 13:29:48.637 [18363] dbg: rules: ran one_line_body rule
> __GENERATE_LEADS ======> got hit: "your business"
>
> This goes on forever.
WTF? If tflags=multiple is supported at all, it should behave properly
(i.e. not hitting over and over on the *same bit of text*).
maxhits was implemented after 3.3.1; is it possible that there are just a
*lot* of instances of "your business" in that test message, and it's
simply hitting all of them?
Can anyone else confirm this on 3.3.1? Run through a test message with
*one* instance of "your business" and get repeated hits on it in
__GENERATE_LEADS?
While __GENERATE_LEADS is recent, there are a lot of tflags=multiple rules
in the base ruleset that have been there for a long time - I'd expect this
to have come up much earlier.
> I tested on Centos7 with sa-update done and rules compiled, this rule does
> not trigger a loop.
You tested 3.3.1 on C7? Or the native 3.4.0, which does implement maxhits?
Are the SA 3.3.1 sources different between the C6 and C7 packages?
> Upgrade is my option, clearly.
>
> Thanks,
>
> Chris
>
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
There is no better measure of the unthinking contempt of the
environmentalist movement for civilization than their call to
turn off the lights and sit in the dark. -- Sultan Knish
-----------------------------------------------------------------------
2 days until Earth Day
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Chris Conn <cc...@abacom.com>.
On 4/18/2018 10:32 AM, Benny Pedersen wrote:
> Chris Conn skrev den 2018-04-18 16:00:
>
>> this is a relatively old install, SA 3.3.1 on Centos6 (stock RPMs)
>
> maybe solved in centos7 ?
>
> i do not use precompiled problems
Hello,
I believe I found the issue. On my Centos6 boxes with SA 3.3.1 (the
maintained version by RedHat/CentOS), using sa-update rules, there is a
loop;
Apr 20 13:29:48.636 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.637 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.637 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.637 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.637 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.638 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.638 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.638 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.639 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.639 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.639 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.640 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.640 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.640 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.640 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.641 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.641 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.641 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.642 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.642 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.642 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.642 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.643 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.643 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.643 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.644 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.644 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.644 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.644 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.645 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.645 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.645 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.646 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.646 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.646 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.646 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.647 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.647 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.647 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.648 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.648 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.648 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.648 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.649 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.649 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.649 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.650 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.650 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.650 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.651 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.651 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.651 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.651 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.652 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.653 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.653 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.653 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.654 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.654 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.654 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.654 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.655 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.655 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.655 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.656 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.656 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.656 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.656 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.657 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.657 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
Apr 20 13:29:48.657 [18363] dbg: rules: ran one_line_body rule
__GENERATE_LEADS ======> got hit: "your business"
This goes on forever.
I tested on Centos7 with sa-update done and rules compiled, this rule
does not trigger a loop.
Upgrade is my option, clearly.
Thanks,
Chris
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Chris Conn <cc...@abacom.com>.
> maybe solved in centos7 ?
>
> i do not use precompiled problems
Hello,
I guess I will soon find out. Not using bayes or anything, most plugins
are disabled actually. Just trying to figure out which one is
misbehaving, as spamd grows to 4Gb of resident memory usage, at 100%
CPU, and eventually croaks with that msg.
Thanks folks,
Chris
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Posted by Benny Pedersen <me...@junc.eu>.
Chris Conn skrev den 2018-04-18 16:00:
> this is a relatively old install, SA 3.3.1 on Centos6 (stock RPMs)
maybe solved in centos7 ?
i do not use precompiled problems