[Mimedefang] Slaves dying unexpectedly with signal 14

[Roland Pope]

----- Original Message ----- >> Thanks Jan for your response.
>> I inserted this code in near the start, and in the global section, of my
>> mimedefang-filter, and got the error:
>> <snip>
>> Jan 18 22:27:48 hosta mimedefang-multiplexor[6491]: Slave 5 stderr: 
>> Argument
>> " at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Loc..." isn't 
>> numeric
>> in alarm at /etc/mail/mimedefang-filter line 95.
>
> Wow, that's very brave. I said UNTESTED and I meant it. I just typed this
> in as an example...

Hey, I did eyeball it to to make sure it wasn't going to recreate my 
filesystem or turn my MX into a SPAM zombie :)

> Hmm... it could also be that perl somehow forgot to install the SIGALRM
> handler... I suddenly recall that that was the case last time this came
> up. Quick check is: is it solved if you disable embedded perl? If it is,
> then you can either leave embedded perl off, send a bug report to
> spamassassin, or try to debug it yourself... Which might get tricky.
I turned the embedded perl off on one of my gateways, after a period of 
time, I started getting the spurious SIGNAL 14's showing up on the MX where 
I was still running MD with embedded perl, but not the one where embedded 
perl was turned off.
Typically, an email was being processed by one MX which started the SIGNAL 
14 errors and tempfailed the message. The email would then try the other MX 
which would result in the SIGNAL 14's happening on that machine too.
My guess, as suggested, is that SpamAssassin and/or one of it's cronies has 
an issue with signalling and this is perhaps being caused, or exasperated by 
the use of embedded perl with MD.

I will run with embedded perl turned off until the next Spamassassin 
release.

Thanks everyone for your help.

Roland