On Tuesday 24 July 2007, Gene Heskett wrote: > On Tuesday 24 July 2007, David Baron wrote: > >> >> 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. > > And I would call ANY distro that starts networking in the S99files > terminally broken. Rename that link so it starts earlier than that. > Earlier and earlier till it complains about something it needs. Then go > rename that one too. > So I would assume either the S35 or the S40 should be OK. I will post the the Debian list and ask about this>
> >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. > > I wonder about that too, as the spamassassin startup make no reference to > sa-update here. Its assumed (theres that word again) that you have set > that function up in a crontab rule, to refresh it about weekly if required. > > Sigh, somebody, please take another look at this mousetrap, its a very > poorly designed version. > Sa must be restarted by such a cron-job and it that cron-job fails and does indeed restart it, spam gets through. I think I started out with something like that. So probably something like if sa_update then exit fi /etc/init.d/spamassassin restart assumming (yipees) sa_update returns 0 if ok, otherwize something else. Maintainer should supply this.
