> >> Humm, with my lashup here that Joanne helped me setup, S78spamassassin > >> starts a few copies of spamd, and fetchmail is started much later in > >> S99local. Its fetchmail that calls procmail, and its procmail that > >> calls the spamd's, so there is no time that SA can be bypassed. > >> > >> I thought everyone was doing it. Somebodies better idea isn't? > > > >Problem is that the S78 will start spamassassin but that start does not > >necessarily get a valid rule-set. For that, the internet connection must > > be up at the time. > > And why would it not be when the network start is S10network?
I have: /etc/rc0.d/S35networking /etc/rc2.d/S99networking /etc/rc3.d/S99networking /etc/rc5.d/S99networking /etc/rc6.d/S35networking /etc/rcS.d/S40networking S99 is what is being hit. This is Debian box originally set up from a Knoppix hd installation. I have not fiddled with any of these. I assume there is decent reason for the numbering schemes for these scripts. The network connection is not immediate. Often must poll several times before it gets logged in. I saw this with repeated attempts by ntpdate to get its connection. I currently try five times with 15 second waits. Sometimes hits the first time, sometimes needs a few tries. >> Problem is that the S78 will start spamassassin but that start does not >> necessarily get a valid rule-set. >This is the bit puzzling me: Why must sa-update complete sucessfully >for spamd to start? The default SA rules should be shipped in the >package, and be placed in (typically) /usr/share/spamassassin; rules >from sa-update will be placed somewhere like /var/lib/spamassassin (by >default), and the SA rule-loading code will check both locations. >Where do you get your SA package from? It sounds like the package >maintainer may need to learn a bit more about how SA works for the next >package release... This is from Debian "Sid" which I assume is legit enough. I discovered that if sa_update failed, spam was getting through which was why I set it up as I did.
