MailScanner defunct processes

[Dave Jones]

>>> [root at server2 MailScanner]# grep -rl 'Error PPS' /usr/lib/perl5
>>> /usr/lib/perl5/site_perl/5.8.8/OLE/Storage_Lite.pm
>>> [root at server2 MailScanner]#
>>>
>> Update:  The Storage_Lite.pm files are identical on the 2 servers.  I
>> tried rpmbuild'ing the module but it looks the same.  How do I
>> troubleshoot what is using this Perl module and can this functionality
>> be disabled by a MailScanner.conf setting?  I don't think we use any
>> OLE document processing.
>>
>> Our Nagios monitoring is now alerting us on some mail loop checks we
>> have in place for the problem server.  Further investigating shows the
>> we had a period of around 1 hour and 20 minutes early this morning
>> that MailScanner did not move any messages from the inbound queue to
>> the outbound queue.  The maillog shows 276 "is whitelisted" messages
>> for a single message ID but that MailScanner process never goes on to
>> the next step.  During this time period, we had almost all (if not
>> all) of the MailScanner processes in a defunct state.  I am pretty
>> sure that the normal MailScanner restart "woke up" the email flow
>> based on the maillog.
>>
>Any chance you could find the problem message and send me a zipped-up
>copy of it for me to work with?
>The only way to disable the Storage_Lite code is to comment out the
>calls to sub "ExtractOle" in Message.pm (in
>/usr/lib/MailScanner/MailScanner). Otherwise it is automatically used
>whenever it sees an attachment which starts with the "magic" strings
>that define a Microsoft Office document.
I ended up commenting out 2 lines that were a single call to UnpackOle
and mail is flowing again with no defunct processes.  We were up to
about 4,000 messages in the mqueue.in this morning and rising fast due
to an email campaign blasting out messages.  We had to do something.
Thanks so much for your temporary fix!

>If we can narrow down the problem to a particular call in Storage_Lite,
>then I can post a bugfix to the maintainer. Without it, there's little I
>can do.
It appears that nearly every message is causing a problem so how can I
accurately pick out one of them that will help you troubleshoot?

>Jules

-- 
Dave Jones