I agree with the fact that the lock is not needed on spamc, but I don't understand why this would produce an error. There are a lot of individuals that use the lock with both spamassassin and spamc as a load control. Is it possible that by using DROPPRIVS=yes removes the permissions necessary to create and write to spamassassin.lock?
The problem with the locking error is related to the DROPPRIVS. With a normal mailbox lock, the lock is created using the name of the mailbox as the root, which is typically owned and only updated using that user's uid. With a filtering recipe, the lock is created using the program's name, but now that must be shared by many different users - one person gets to create it, and everybody else gets the error message. Without DROPPRIVS, the lock is created fine, but now everybody has to queue up on that lock, so you only get one spamc/spamd process pair running.
-- Pete `-_-' http://www.well.com/user/wolfy http://www.fotolog.net/wolfy/
Blutarsky's Axiom:
Nothing is impossible for the man who will not listen to reason.
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
