procmail
[Top] [All Lists]

Re: procmail suid and sendmail

2003-04-07 05:47:43
On Fri, 4 Apr 2003, Professional Software Engineering wrote:

At 08:27 2003-04-04 -0500, Dave Stern - Former Rocket Scientist did say:
<snip... snip... snip...>
Second, we have the latest sendmail installed sgid with procmail as the
LDA and a systemwide procmailrc everyone runs.  Periodically, I see messages:

   timeout waiting for input from local during Draining Input

Periodically you see these messages WHERE?  If in the system log, what
service are they attributed to?

Unless you include those details, when you dump the message here, you're
either expecting that people have had the same problem as you, or that
they'll go searching in the support forums for _another_program_ to find
the cause.  Given that, the least you could do is specify where the message
comes from.

FTR, the FIRST result in deja when searching for the error string as a
literal was:

<http://groups.google.com/groups?q=+timeout+waiting+for+input+from+local+during+Draining+Input&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=b4ssv7%24957%241%40mserv2.dl.ac.uk&rnum=1>

There are several other equally applicable messages returned from a direct
search on the error message in question.

The error is also mentioned at:
         <http://www.sendmail.org/~ca/email/smenhanced.html>

I'm told I should look at whether the LDA (procmail) is generating too much
output for sendmail. How can I check this? How can I throttle it back if it
is a problem?

Generating 'too much output', eh?  Procmail itself shouldn't.  You didn't
post a procmailrc, or even a hint of it, so we certainly can't give you
pointers on what you're doing there.

Perhaps programs called from your procmailrc are emitting a lot of text to
stdout.  Have you tried running your rules within a sandbox to evaluate
what it is they're outputting firsthand?

Related to this, I'm running an older version of procmail, perhaps upgrading
to 3.22 might solve it?

'an older verison of procmail'?  Such as?  I didn't see the version
mentioned anywhere in your post.


Thanks for your input. I apologize for more details were lacking. But this
sounded like a general problem based in my initial research. The sendmail
folks pointed me elsewhere and in fact the sendmail URL doesn't really say
how to fix it, just that this is a know problem. This is sorta like throwing
a problem between a sw and hw engineer; each points to the other as the
source.

If it helps, here are more details:
This is running on a solaris 2.8  sb1000 dual processor with only 512M of
RAM, also running DCE/DFS. Procmail is version 3.14, not suid. Sendmail is
8.12.9 running sgid, LDA lines are as follows:

Mlocal,         P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=EnvFromL/Hdr
FromL, R=EnvToL/HdrToL,
                T=DNS/RFC822/X-Unix,
                A=procmail -Y -a $h -d $u
Mprog,          P=/usr/lib/smrsh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/Hd
rToL, D=$z:/,
                T=X-Unix/X-Unix/X-Unix,
                A=smrsh -c $u

The message  appears in syslog sporadically. I have found no cause-and-affect
as to when they occur or what (who) triggers it) but the system appears busy
at that time). The systemwide procmailrc is empty. Users that have their own
procmailrc are doing simple filtering eg

:0:
* ^To:.*special
MAILDIR/some-mailbox

or kicking off an older version of spamassassin (2.1X) via:

:0fw
| /usr/local/SpamAssassin/spamassassin -P

I was considering raising timeouts altho that might have other repercussions
(I don't have the source with me at hand but someone wrote a great article
on tuning sendmail noting that most timeout values are way too high).


 =-=-=-=-=-=-=-=-=-=-=-=-  generated by /dev/dave -=-=-=-=-=-=-=-=-=-=-=-=-=-=
 David Stern                                            University of Maryland
                Institute for Advanced Computer Studies


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>