Steve Martin wrote: > Sat Aug 20 00:28:36 2005 [16014] info: spamd: processing > message <[EMAIL PROTECTED]> 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
