SA times out

[Glenn Steen]

On 04/04/2008, Kai Schaetzl <maillists at conactive.com> wrote:
> Glenn Steen wrote on Fri, 4 Apr 2008 09:57:21 +0200:
>
>
>  > Sorry if you already supplied this, but what do you have for the
>  > different SA paths in MailScanner.conf?
>
>
> Good suggestion. There must have been indeed a bug in that MS version.
>
>  # The rules created by the "sa-update" tool are searched for here.
>  # This directory contains the spamassassin/3.001001/updates_spamassassin_org
>  # directory structure beneath it.
>  # Only un-comment this setting once you have proved that the sa-update
>  # cron job has run successfully and has created a directory structure under
>  # the spamassassin directory within this one and has put some *.cf files in
>  # there. Otherwise it will ignore all your current rules!
>  # The default location may be /var/opt on Solaris systems.
>  SpamAssassin Local State Dir = /var/lib
>
>  A newer MS version has this:
>
>  # The rules created by the "sa-update" tool are searched for here.
>  # This directory contains the 3.001001/updates_spamassassin_org
>  # directory structure beneath it.
>  # Only un-comment this setting once you have proved that the sa-update
>  # cron job has run successfully and has created a directory structure under
>  # the spamassassin directory within this one and has put some *.cf files in
>  # there. Otherwise it will ignore all your current rules!
>  # The default location may be /var/opt on Solaris systems.
>  SpamAssassin Local State Dir = # /var/lib/spamassassin
>
>  It seems the code is the same, but documentation (compare the second line!)
>  and update_mailscanner_conf where not correct. I changed that line to
>  SpamAssassin Local State Dir = /var/lib/spamassassin
>  and it uses now the correct rules.
Go all the way and set a hashmark efore the path (effectively leaving
the setting blank, which is how the commandline spamassassing tool
does it... See if that doesn't work even better.

>  However, MS still times out. The first time I tried it almost came to an end,
>  but eventually timed out, anyway. It definitely takes much longer than via
>  command-line. I then upped the time-out to 240 seconds, but now I hit a new
>  phenomenon. The message is just removed from mqueue.in and Mailwatch shows
>  again that it times out. But MailScanner doesn't print anymore (to the log,
>  it doesn't do this in the debug output) that it hits a timeout. It almost
>  immediately finishes and doesn't process the message. Could this be the sa
>  cache of MS? If so, I don't understand why that didn't hit earlier and also I
>  don't see anything about it in the debug output.
See Jules suggestion... alluded/implied, but still... Time to
upgrade;-). Or turn off the SA cache.

>  >
>  > >  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...
>  > mostly:-).
>
>
> The command-line SA doesn't have this problem. It's the Mail::Spamassassin
>  perl module. Either it needs these data or it should not get these data as it
>  can determine them by itself (then they shouldn't be set in MailScanner.conf)
>  - I don't know.
*If* you need it is pretty obvious... MailScanner won't have a working
SA, no rules from the sa-update will fire, while they will with the
cmd-line tool... You likely don't need it. Try it and see what
happens:-).
Perhaps best way to test is to do that long-overdue update:-):-)

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se