Reliably reloading configuration?

[Steve Weigold]

Mark, (and other helpers)

Thanks for your response.  Apparently my issue with list messages was 
due to another email problem on a different server which has been 
resolved.  It was unrelated to the list.  I only noticed it because I 
was looking for list replies.  It's what happens when you screw with too 
many things at once.

On 12/10/2015 5:12 PM, Mark Sapiro wrote:
>> In any case, I'm finding that my problem was less about finding where to
>> put score modifications and other custom rules, and apparently more
>> about reliably reloading the configuration for SpamAssassin.   I've been
>> fighting this all day and I'm finding that the problem seems to be that
>> even with restarts, SpamAssassin doesn't seem to be reliably re-reading
>> the configuration.
>
> Are you running sa-compile? Did you see my reply at
> <http://lists.mailscanner.info/pipermail/mailscanner/2015-December/102815.html>?
>
> Your post at
> <http://lists.mailscanner.info/pipermail/mailscanner/2015-December/102814.html>
> implies you are using compiled rules. Thus, any time you modify rules
> you have to run sa-compile.

sa-compile doesn't seem to be doing for me either.  I'm not 
'intentionally' using compiled rules, but apparently the stock rules are 
compiled?  I'm using the (generally) default spamassassin installation 
in Debian Jessie.

Following your post, I made a small change to my custom rule score, 
tried sa-compile and then both a spamassassin and mailscanner restart 
and then sent a test message.  Score was not changed in the message as 
it was logged in MailWatch, nor in the actual header in the received 
message.

Oddly, some time later (unsure, t > 1 hour) I happened to notice a 
message go by on MailWatch which would have passed the custom rule, and 
the updated score was present in the header without further intervention 
from me. I'd given up for the day and just came back to check following 
a food break.

I wondered if there was something happening as a cron job that was 
performing some crucial additional step I was missing, but a review of 
both the spamassassin and mailscanner cron jobs finds nothing _obvious_ 
that I'm missing. (not to say it's not there...)

The score changes I'd made previously to some of the stock rules took 
effect "magically" at some point during my work yesterday, and I'm sure 
it was without an sa-compile from me.  Not to say it wasn't just 
coincidental with one from a cron job.

For the sake of verification, when I do a mailscanner or a spamassassin 
restart, I do just

/etc/init.d/mailscanner restart and
/etc/init.d/spamassassin restart

On a possibly related note, reviewing the logs, (syslog, mail) I can 
clearly see where and when I restarted MailScanner.  SpamAssassin on the 
other hand, is leaving no evidence of a restart in either of these 
logs.  This seems odd.

Also, my understanding of MailScanner's use of SpamAssassin is that it's 
invoked by MS and does NOT use SA in daemon mode.  Assuming this is 
correct, I then question the value of restarting SpamAssassin, at least 
by restarting the daemon as I'm doing above.   Related, I see in 
MailWatch that MailScanner has 5 children indicated.  Presumably these 
are SA?  I'm wondering if the "delay" in my updated configuration taking 
effect is because SA really isn't restarting properly, or doesn't happen 
until some time later when SA child processes age off and are replaced.  
I'm beginning to suspect I have a subtle error in my MailScanner or 
SpamAssassin configuration.

Perplexed.  I feel like I'm being careful in following a strict 
procedure when I test changes, but this one is eluding me.  I appreciate 
everyone's help with this.

Thanks.
Steve







-- 
------------------------------------------------------------------------
Steve Weigold
Weigold Enterprises
Cell - 513-365-0446
www.weigoldenterprises.com
www.facebook.com/weigoldenterprises
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mailscanner.info/pipermail/mailscanner/attachments/20151211/ae1b609b/attachment.html>