http://bugzilla.spamassassin.org/show_bug.cgi?id=3828
------- Additional Comments From [EMAIL PROTECTED] 2004-11-15 14:46 ------- 'Wait a second, I think I stumbled upon something here. SpamD, at least on our servers, runs in a way that is linked to Exim. So, when Exim receives a mail message, it locks the MailBox File until SpamAssassin is done scanning the mail message and passes it back to Exim. So, when a SpamAssassin process takes a shit and dies improperly, Exim doesn't know about it, thus the MailBox files remain locked, thus unable to be read or written to until the zombie is killed, aka reboot.' I'm not sure what this means. does this setup require that SA do something in particular before Exim will unlock the mailbox? is there a way to deal with these possible failure cases more resiliently? There's a myriad of ways for the SA scanning step to not happen or not complete, some due to bugs in SA, some due to resource shortages, some due to timeouts, and some due to sunspots or similar wierdness. We (obviously) can try to avoid that, but this is computer science, and nothing's perfect. I would suggest using a more resilient system that can cope with that; for example, if the SA process returns without a result, the glue code should treat the message as non-spam, deliver it, and unlock the mailbox. (This is what spamc does, for example.) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
