CentOS - Dec 2007 - Sendmail: timeout waiting for input from local during Draining Input

Hi folks,

I've recently replaced a RedHat EL 3.x system with a CentOS 5 system
(fully yum'd as of Tuesday).  This was a full-pave install, although
we did copy the sendmail.mc from the original system.  

Now I get a lot of this in my logs:

Dec  7 11:47:38 mail sendmail[20117]: lB7Gl6w0020116: timeout waiting for input
from local during Draining Input

The only thing even remotely credible is a Sendmail Known Bugs page
which suggests it is a chatty local delivery agent, but since this is
happening with outbound messages I don't think I believe this.

Does anyone have any ideas what Sendmail is trying to tell me here?

-- 
 /\oo/\
/ /()\ \ David Mackintosh | 
         dave at xdroop.com  | http://www.xdroop.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20071207/7630d51c/attachment-0003.sig>

On Fri, Dec 07, 2007 at 11:54:26AM -0500, David Mackintosh
wrote:
> I've recently replaced a RedHat EL 3.x system with a CentOS 5 system
> (fully yum'd as of Tuesday).  This was a full-pave install, although
> we did copy the sendmail.mc from the original system.  
> 
> Now I get a lot of this in my logs:
> 
> Dec  7 11:47:38 mail sendmail[20117]: lB7Gl6w0020116: timeout waiting for
input from local during Draining Input
> 
> The only thing even remotely credible is a Sendmail Known Bugs page
> which suggests it is a chatty local delivery agent, but since this is
> happening with outbound messages I don't think I believe this.
> 
> Does anyone have any ideas what Sendmail is trying to tell me here?
Further to this, I have discovered that what Sendmail is trying to
tell me is "procmail and dovecot are not playing nicely together".

What is happening is that I have a large amount of mail coming and
going, and when procmail tries to deliver to a mailbox (in mbox
format, in /var/spool/mail/$user, currently 12MB in size but can grow
MUCH larger) that dovecot is actively using, procmail blocks -- and
so do all the other procmail processes waiting to deliver to this
mailbox.  Sendmail gets annoyed waiting for these blocked procmail
processes, and so fills my logs with the error message above.

If I do a "service dovecot stop", then the queued procmail processes
all
drain their messages into the affected mailbox, and the problem goes away
for a little while after dovecot is restarted.

Naturally, the hack of stopping dovecot every so often isn't really
a solution.

So the question is: how do I get dovecot and procmail to play nice?
Is the solution to change to a maildir type inbox spool?

-- 
 /\oo/\
/ /()\ \ David Mackintosh | 
         dave at xdroop.com  | http://www.xdroop.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20071207/d82020f0/attachment-0003.sig>

on 12/7/2007 8:31 PM David Mackintosh spake the
following:
> On Fri, Dec 07, 2007 at 11:54:26AM -0500, David Mackintosh wrote:
>> I've recently replaced a RedHat EL 3.x system with a CentOS 5
system
>> (fully yum'd as of Tuesday).  This was a full-pave install,
although
>> we did copy the sendmail.mc from the original system.  
>>
>> Now I get a lot of this in my logs:
>>
>> Dec  7 11:47:38 mail sendmail[20117]: lB7Gl6w0020116: timeout waiting
for input from local during Draining Input
>>
>> The only thing even remotely credible is a Sendmail Known Bugs page
>> which suggests it is a chatty local delivery agent, but since this is
>> happening with outbound messages I don't think I believe this.
>>
>> Does anyone have any ideas what Sendmail is trying to tell me here?
> 
> Further to this, I have discovered that what Sendmail is trying to
> tell me is "procmail and dovecot are not playing nicely
together".
> 
> What is happening is that I have a large amount of mail coming and
> going, and when procmail tries to deliver to a mailbox (in mbox
> format, in /var/spool/mail/$user, currently 12MB in size but can grow
> MUCH larger) that dovecot is actively using, procmail blocks -- and
> so do all the other procmail processes waiting to deliver to this
> mailbox.  Sendmail gets annoyed waiting for these blocked procmail
> processes, and so fills my logs with the error message above.
> 
> If I do a "service dovecot stop", then the queued procmail
processes all
> drain their messages into the affected mailbox, and the problem goes away
> for a little while after dovecot is restarted.
> 
> Naturally, the hack of stopping dovecot every so often isn't really
> a solution.
> 
> So the question is: how do I get dovecot and procmail to play nice?
> Is the solution to change to a maildir type inbox spool?
> 
You need to make sure that all three processes are using the same lock type, 
with sendmail V8.13 is fcntl. Sometimes I see dovecot defaults with flock 
enabled, and it could be causing the lock contentions. Also make sure that you 
didn't somehow enable dovecot's deliver while procmail is still enabled.

-- 
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!