Diagnosing SpamAssassin timeouts...

[Julian Field]

In your MailScanner.conf file, set "Debug = yes" and "Debug SpamAssassin =
yes".

then kill MailScanner and wait for a few messages to accumulate in the
mqueue.in.
Then
         check_mailscanner
and watch where the output pauses. Thump Ctrl-S when it pauses anyway and
read the debug output to see what it was doing. Anything to do with
cloudmark is Razor having trouble. Most of the others are more obvious.

At 13:07 05/11/2003, you wrote:
>Hello all...
>
>I'm still running MailScanner 4.21 (i.e. I should upgrade), so
>apologies as always if this is a feature that has 'creeped' in.
>
>We had backlogs recently (Postfix and MS, SA 2.6, DCC, Razor2 and
>multiple AV engines) which lead me to look more at the time it was
>taking to do various tests.
>
>Since then, I've disabled Razor2 completely, and switched to DCC with
>the dccifd interface (which seems to be working fine)...
>
>My problem, though, is in identifying where SA is failing... eventually
>(based on the MS configuration) an SA run will 'time out', but I have no
>idea whether hanging up on DCC, or Razor or whatever is causing the most
>'time spent'.
>
>Reading various threads on the list, people comment about 'Razor having
>problems today' or 'I'm experiencing timeouts with DCC', but I guess I'm
>wondering what they did to isolate that conclusion...
>
>Does SA return this information at all in a way MailScanner can use it
>(to provide more useful logged error messages), or am I getting this all
>wrong?
>
>Thanks...
>
>
>
>--------------------------------------------------------------------------------------------------->
>Peter Bates, Systems Support Officer, Network Support Team.
>London School of Hygiene & Tropical Medicine.
>Telephone:0207-958 8353 / Fax: 0207- 636 9838

--
Julian Field
www.MailScanner.info
MailScanner thanks transtec Computers for their support

PGP footprint: EE81 D763 3DB0 0BFD E1DC  7222 11F6 5947 1415 B654