[Mimedefang] Slaves dying unexpectedly with signal 14

[Frank Doepper]

Am 18.01.06 um 02:37 schrieb Roland Pope:

> I posted an email some time back asking about MD slaves that were
> unexpectedly terminating with a signal 14. David Skoll mentioned at the time
> that it was possibly a perl module generating this signal 14 which was
> somehow not being handled and was causing the slaves to die.
> At the time, I upgraded a few of the perl modules, and the problem seemed to
> go away.
> Unfortunately, it is back.
> Once the errors start occuring, a restart seems to stop it happening for a
> time, but eventually, it returns. This error is occuring on two seperate
> mail exchangers (Which are running the same software versions).
> I am running mimedefang 2.53 under CentOS linux 3.6
> Can anyone give me any pointers at all as to how I can go about further
> tracking down what is generating these signal 14's?? Can I arm some sort of
> signal handler in my filter and generate some sort of trace back?
> Any sort of help would be appreciated.
> The log messages I am getting are as follows:
> <snip>
> Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Slave 4 died
> prematurely -- check your filter rules
> Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Reap: Idle slave 4 (pid
> 10634) exited due to signal 14 (SLAVE DIED UNEXPECTEDLY)
> Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Slave 4 resource usage:
> req=44, scans=8, user=14.830, sys=1.360, nswap=0, majflt=10062,
> minflt=111990, maxrss=0, bi=0, bo=0
> Jan 18 19:00:57 hosta mimedefang[6477]: Error from multiplexor: ERR No
> response from slave
> </snip>

Hi,

here I get the same. Investigation has shown that SpamAssassin and 
Flock are the reason why this is happening. I use Debian etch, embedded 
Perl, SA-3.2.1, MD-2.61 and in spamassassin/local.cf:

   lock_method flock

because "nfssafe" brings even worse results in md-embedded-multiplexed 
environment.

I can reproduce the error by starting

   sa-learn --force-expire

(which locks the Bayes-DB R/W) - then the slaves begin dying. After 
completion everything is ok again.

So, now I try to use

   bayes_auto_expire 0

to have a chance to circumvent the problem by expiring the Bayes-DB by 
hand (or cron) in times of little load.

But, it would be much better, if there was a way to make SA really ready 
for MD. ;) Anyone any clues? Patching Mail/SpamAssassin/Locker/Flock.pm? 
Using MySQL?

regards,
Frank.