Reliably reloading configuration?

Mark Sapiro mark at msapiro.net
Fri Dec 11 19:10:02 UTC 2015


On 12/11/2015 08:32 AM, Steve Weigold wrote:
> 
> 
> 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.


How are you running sa-compile?  In a default debian/ubuntu environment,
sa-compile should be run 'su - debian-spamd'


> 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...)


Again, a default debian/ubuntu spamassassin has
/etc/cron.daily/spamassassin which will update rules and run sa-compile.


> 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.


'grep spamd /var/log/mail.log' should show something.


> 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.


I think the above is correct, at least for 'standard' MailScanner (I
think there is a spamd patch, but it's non-standard). So yes,
restarting/reloading spamd (spamassassin) shouldn't be necessary.


> Related, I see in
> MailWatch that MailScanner has 5 children indicated.  Presumably these
> are SA?


They are MailScanner workers, each of which will invoke spamassassin as
necessary when processing messages.


> 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.


As noted above, I think restarting SA is a red herring here. It is more
likely an sa-compile issue of some kind.

Restarting MailScanner should definitely restart its children. If for
some reason this isn't happening, they will die of old age after (I
think) 2 hours which may explain something.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


More information about the MailScanner mailing list