Noah Meyerhans schrieb am Sonntag, den 31. Januar 2010: Hi,
> On Thu, Jan 28, 2010 at 11:43:49AM -0700, nomad Bellcam wrote: > > yes. i am not sure if amavisd-new should be responsible, since i > > believe spamassassin is running under its control, so to speak, or if > > spamassassin should detect that it is running under the control of > > another system (amavisd-new), and govern itself accordingly, > > restarting its parent when necessary. > > I'm not familiar with amavisd-new, and I don't understand why it needs > spamassassin to do this work for it. How is it actually using > spamassassin in a way that requires amavisd-new to be restarted when > data specific to spamassassin changes? Why is reloading spamd not > sufficient? It does not use spamd (and its good it doesn't for several reasons). Every amavisd child creates an spamassassin object during creating time. A child lives $max_requests (or a timeout value) until it gets restarted. In this time it would have an old ruleset if they got updated in the meantime with sa-update. > I would think that amavisd-new should either utilize spamd, or handle > rule updates on its own. Sure, we can ship our own sa-update but I don't think that this is would be a good decision. In fact amavisd-new is not the only package with that problem. Everything which loads spamassassin as a library will run into the same problem, spampd is the first package which comes into my mind. Unfortunatly the spamassassin API is not able to inform users about the fact that there was a ruleset update, otherwise I would just restart the child. Thats the reason why I think this should handled within spamassassin, what do you think about a directory where software which needs to get informed about ruleset updates can drop a shell snipplet to get reloaded/restarted? Thanks for your attention Alex
signature.asc
Description: Digital signature
