SA 3.1.7 returning no result to MS?

[David Lee]

On Mon, 13 Nov 2006, David Lee wrote:

> On Mon, 13 Nov 2006, Matt Kettler wrote:
>
> > [...]
> > Check your mail logs for messages along the lines of "SpamAssassin timed out and
> > was killed"
>
> There are a few "... was killed, failure <n> of 20" but they don't appear
> near the emtpy SA returns, and although they build in series, the "<n>"
> don't seem to reach anywhere near the "20".
>
> There's nothing else nearby in the log that seems linked.  There are some
> "SpamAssassin cache hit for message XXX" next to the failures, but that
> same process both before after returns non-empty with such incidents (as
> if these incidents are sporadic, rather than an MS process going long-term
> bad/corrupt).
>
> If someone who knows SA (3.1.7) or MS (4.56.8) internals can dream up some
> debug/log statements, I'd be happy to try to patch them in and watch what
> happens.

Anyone?  Julian?  Matt?

Looking a little deeper, it seems that in the "MailScanner/SA.pm" module
at the "eval { ...}" near line 800 (MS 4.56.8) all the results from:

    $pipe->reader();
    local $SIG{ALRM} = sub { die "Command Timed Out" };
    alarm MailScanner::Config::Value('spamassassintimeout');
    $SAHits = <$pipe>;
    #print STDERR "Read SAHits = $SAHits " . scalar(localtime) . "\n";
    $AutoLearn = <$pipe>;
    $SAHitList = <$pipe>;
    $SAReport  = <$pipe>;
    #print STDERR "Read SAHitList = $SAHitList " . scalar(localtime) . "\n";
    # Not sure if next 2 lines should be this way round...
    waitpid $pid, 0;
    $pipe->close();
    $PipeReturn = $?;

are coming back empty.  Hence the syslog entry:
   Message ... is not spam, SpamAssassin (cached, score=0, required 6, autolearn=)

This suggests that SA's expected behaviour would be that a 'good' return
would always be accompanied by real, non-empty, data.  This, I presume, is
what has always happened historically.

But it now seems, after upgrade to SA 3.1.7, that SA occasionally provides
empty data on a 'good' return: inconsistent.

If this is the case, it suggests a likely bug in SA.  Now I'll readily
acknowledge that the place to fix that properly would be SA.

But right now that still leaves us with a very live, very nasty problem of
SA sometimes (randomly?) failing to work under MS, which is dire for
sites which rely on SA.

Is there some workaround we can put into MS to try to confirm this
debugging) to detect this inconsistent return ('good' return code but
empty data)?  (If this really is an SA 3.1.7 bug, then it is still prudent
for MS to try to handle it if reasonably possible because of the latent
delay both of SA releases and of end-user sites upgrading after that.)

Meanwhile, are there any SA folk here with whom I could work to try to get
this taken up with the SA maintainers?


-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :