spurious __alarm__ messages in spamd log

[Steve Martin <st...@planomartins.com>]

Sat Aug 20 00:28:36 2005 [16014] info: spamd: processing message  
<20...@cheezmo.com> for filter:88
Sat Aug 20 00:28:42 2005 [16014] error: __alarm__
Sat Aug 20 00:28:42 2005 [16014] error: __alarm__
Sat Aug 20 00:28:49 2005 [16014] info: spamd: identified spam  
(35.1/5.0) for filter:88 in 13.7 seconds, 2360 bytes.

Anyone know how one might track these down (what debug areas to start  
with)?  I've seen 2 in the last 30 hours or so.

Rerunning the same message through with spamc gives the same score,  
but no __alarm__ messages.

SA 3.1rc1


--
Steve Martin                              http://www.cheezmo.com/
Smart Calibration, LLC           http://www.smartcalibration.com/
The Widescreen Movie Center            http://www.widemovies.com/
Letterboxed Movie TV Schedule  http://www.widemovies.com/lbx.html

RE: spurious __alarm__ messages in spamd log

[Sander Holthaus - Orange XL <in...@orangexl.com>]

Steve Martin wrote:
> Sat Aug 20 00:28:36 2005 [16014] info: spamd: processing
> message <20...@cheezmo.com> for filter:88
> Sat Aug 20 00:28:42 2005 [16014] error: __alarm__ Sat Aug 20
> 00:28:42 2005 [16014] error: __alarm__ Sat Aug 20 00:28:49
> 2005 [16014] info: spamd: identified spam
> (35.1/5.0) for filter:88 in 13.7 seconds, 2360 bytes.
> 
> Anyone know how one might track these down (what debug areas
> to start with)?  I've seen 2 in the last 30 hours or so.
> 
> Rerunning the same message through with spamc gives the same
> score, but no __alarm__ messages.
> 
> SA 3.1rc1

They are quite easy to find in the code. Looking at them, I can only say
that I don't understand how they get used in the first place. It seems to be
using the return value of alarm, but I don't have a clue why. It returns the
value of the previous timer, or 0. But from what I can see and how it us
used, you only want to set it back to zero.

Next to that, if an eval which has an alarm, fails, the alarm isn't
imidiately reset, but calls some other code first (
$permsgstatus->leave_helper_run_mode(); ).

Last, I would say the evals are quite wide. Beside the actual code that
calls Pyzor/DCC, the also contain or other bits, meaning they can time out
even though the called app ran succesfull (but took long, but still less
than the specified timeout by the user).

Kind Regards,
Sander Holthaus 

Re: spurious __alarm__ messages in spamd log

[Andy Jezierski <aj...@stepan.com>]

Steve Martin <st...@planomartins.com> wrote on 08/20/2005 12:42:44 AM:

> Sat Aug 20 00:28:36 2005 [16014] info: spamd: processing message 
> <20...@cheezmo.com> for filter:88
> Sat Aug 20 00:28:42 2005 [16014] error: __alarm__
> Sat Aug 20 00:28:42 2005 [16014] error: __alarm__
> Sat Aug 20 00:28:49 2005 [16014] info: spamd: identified spam 
> (35.1/5.0) for filter:88 in 13.7 seconds, 2360 bytes.
> 
> Anyone know how one might track these down (what debug areas to start 
> with)?  I've seen 2 in the last 30 hours or so.
> 
> Rerunning the same message through with spamc gives the same score, 
> but no __alarm__ messages.
> 
> SA 3.1rc1

I've been getting these for a few months, see bug 4415, doesn't seem to 
cause any problems, eg. nothing seems to be slipping through, just dirties 
up the log files.

But it'd be nice if someone could track it down though.

Andy