Using sa-compile are local rules compiled?

[John Horne <jo...@plymouth.ac.uk>]

Hello,

We are running SpamAssassin 3.3.2 on a CentOS 5.9 server. sa-update runs
via a daily cron job, and we have modified that to run sa-compile as
well. However, there are some questions:

sa-compile is run without any options. So what I am unsure of is whether
our local rules (in /etc/mail/spamassassin/local-spam.cf) are compiled
as well or not?

The man page for sa-compile says that the '--siteconfigpath' option
defaults to /etc/mail/spamassassin which I assume implies that our local
rules would be compiled?

If they are, and we want to change our local rules, then I assume we
would have to re-compile all the rules before restarting SpamAssassin?



Thanks,

John.

-- 
John Horne, Plymouth University, UK
Tel: +44 (0)1752 587287    Fax: +44 (0)1752 587001

Re: Using sa-compile are local rules compiled?

[RW <rw...@googlemail.com>]

On Sun, 21 Apr 2013 19:47:49 +0100
John Horne wrote:


> > That's the received wisdom, but I've never seen a definitive reason
> > why. Compiled rules are intended to co-exit with non-compiled rules,
> > and from my limited testing, rules behave correctly when they are
> > added, removed or modified without recompiling. However I have seen
> > one case where a rule wasn't working properly and was apparently
> > fixed by a recompile, but I suspect that was a specific bug. 
> > 
> Thanks for the reply. I (now) gather that compilation actually only
> applies to 'body' rules. We don't have too many of those, so generally
> for non-body local rules a simple restart of SA works immediately. I
> suspect that for the body rules we never noticed that they only
> started to be hit the following day (recompiling of rules occurs each
> night). We would have simply assumed that the rule didn't have any
> hits until that time. It is, of course, something we will now bear in
> mind :-)

No, they should work immediately after the restart.

As I said "from my limited testing, rules behave correctly when they are
added, removed or modified *without* recompiling". That's to say I
tried the obvious test cases:

- adding a new local body rule and testing that it worked
- removing a local body rule that's been previously compiled, and
  testing that it stopped working
- modifying a local body rule that's been previously compiled, and
  testing that the new version works and the compiled version doesn't 


Whenever I've edited local rules, restarted the daemon and then
tested, it's just worked. And you can see from the detailed debug that
it was intended to work. 

The one aberration was when I once just happened to notice a
long-standing rule wasn't working and a recompile fixed the problem. I
don't know whether it's relevant or not. 

Re: Using sa-compile are local rules compiled?

[John Horne <jo...@plymouth.ac.uk>]

On Thu, 2013-04-18 at 14:08 +0100, RW wrote:
> On Wed, 17 Apr 2013 21:40:33 +0100
> John Horne wrote:
> 
> > Hello,
> > 
> > We are running SpamAssassin 3.3.2 on a CentOS 5.9 server. sa-update
> > runs via a daily cron job, and we have modified that to run
> > sa-compile as well. However, there are some questions:
> > 
> > sa-compile is run without any options. So what I am unsure of is
> > whether our local rules (in /etc/mail/spamassassin/local-spam.cf) are
> > compiled as well or not?
> 
> They are for me, but it's easy enough to test. Find a few *simple*
> local body rules and grep for them under the "compiled" directory.
> 
> > The man page for sa-compile says that the '--siteconfigpath' option
> > defaults to /etc/mail/spamassassin which I assume implies that our
> > local rules would be compiled?
> > 
> > If they are, and we want to change our local rules, then I assume we
> > would have to re-compile all the rules before restarting SpamAssassin?
> 
> That's the received wisdom, but I've never seen a definitive reason
> why. Compiled rules are intended to co-exit with non-compiled rules,
> and from my limited testing, rules behave correctly when they are added,
> removed or modified without recompiling. However I have seen one case
> where a rule wasn't working properly and was apparently fixed by a
> recompile, but I suspect that was a specific bug. 
> 
Thanks for the reply. I (now) gather that compilation actually only
applies to 'body' rules. We don't have too many of those, so generally
for non-body local rules a simple restart of SA works immediately. I
suspect that for the body rules we never noticed that they only started
to be hit the following day (recompiling of rules occurs each night). We
would have simply assumed that the rule didn't have any hits until that
time. It is, of course, something we will now bear in mind :-)



John.

-- 
John Horne, Plymouth University, UK
Tel: +44 (0)1752 587287    Fax: +44 (0)1752 587001

Re: Using sa-compile are local rules compiled?

[RW <rw...@googlemail.com>]

On Wed, 17 Apr 2013 21:40:33 +0100
John Horne wrote:

> Hello,
> 
> We are running SpamAssassin 3.3.2 on a CentOS 5.9 server. sa-update
> runs via a daily cron job, and we have modified that to run
> sa-compile as well. However, there are some questions:
> 
> sa-compile is run without any options. So what I am unsure of is
> whether our local rules (in /etc/mail/spamassassin/local-spam.cf) are
> compiled as well or not?

They are for me, but it's easy enough to test. Find a few *simple*
local body rules and grep for them under the "compiled" directory.

> The man page for sa-compile says that the '--siteconfigpath' option
> defaults to /etc/mail/spamassassin which I assume implies that our
> local rules would be compiled?
> 
> If they are, and we want to change our local rules, then I assume we
> would have to re-compile all the rules before restarting SpamAssassin?

That's the received wisdom, but I've never seen a definitive reason
why. Compiled rules are intended to co-exit with non-compiled rules,
and from my limited testing, rules behave correctly when they are added,
removed or modified without recompiling. However I have seen one case
where a rule wasn't working properly and was apparently fixed by a
recompile, but I suspect that was a specific bug. 

Personally, it wouldn't bother me to have compilation deferred for a
few hours.