SA times out
glenn.steen at gmail.com
Fri Apr 4 08:57:21 IST 2008
On 03/04/2008, Kai Schaetzl <maillists at conactive.com> wrote:
> Kai Schaetzl wrote on Wed, 02 Apr 2008 21:33:36 +0200:
> I found out later that the message actually scanned was not the one I wanted
> to scan but the SA default message that is used on start up. The long wait at
> dbg: bayes: untie-ing simply is MS waiting for the real message.
> However, this doesn't change anything in this respect:
> >  dbg: config: using "/usr/share/spamassassin" for sys rules pre
> > files
> >  dbg: config: using "/usr/share/spamassassin" for default rules dir
> >  dbg: config: read file /usr/share/spamassassin/10_default_prefs.cf
> SA run under MS uses the wrong config directories. This seems to result in a
> much longer time for processing the rules. Maybe there is more. There are
> different hits than for the command-line SA and it takes *much* longer in the
> body scan phase. So, it eventually times out under MS.
> I can't see a reason why this might happen. SA is identified as
> dbg: generic: SpamAssassin version 3.2.4
> I compared the Mail/Spamassassin in /usr/lib/perl5/site_perl/5.8.8/Mail with
> the one built by the source and they are identical except for dates (it seems
> the Perl upgrade process replaces an existing file only when it got changed,
> otherwise it keeps the existing file with the old date). I have some more,
> very old perl directories with different names in /usr/lib. However, if any
> of these would get used for a very obscure reason then it couldn't report
> 3.2.4 as the SA version. Anyway, I set all permissions to access these
> directories to 0, no change.
Sorry if you already supplied this, but what do you have for the
different SA paths in MailScanner.conf?
> What's wrong here, Jules? Could this be a problem with this somewhat old
> version of MS? (4.54.6)
Might be, there's been a lot of water under the bridge... and all that:-).
ISTR there being a rather heated discussion back somewhere there on
how to make MS notice the sa-update stuff, leading to some rather bad
setups with wrongly specified paths in MailScanner.conf (a modern SA
should be able to find these things by itself, no need to "help" it...
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
More information about the MailScanner