Here's a couple:

$ grep g8QGlQbi016840 sendmail.log
Sep 26 12:48:46 bugs sendmail[16840]: g8QGlQbi016840: lost input channel
from loopback [127.0.0.1] to MTA after rcpt
Sep 26 12:48:46 bugs sendmail[16840]: g8QGlQbi016840:
from=<[log in to unmask]>, size=0, class=0, nrcpts=34,
proto=ESMTP, daemon=MTA, relay=loopback [127.0.0.1]

$ grep g8QGlQbi020196 sendmail.log
Sep 26 12:48:46 bugs sendmail[20196]: g8QGlQbi020196: lost input channel
from loopback [127.0.0.1] to MTA after rcpt
Sep 26 12:48:46 bugs sendmail[20196]: g8QGlQbi020196:
from=<[log in to unmask]>, size=0, class=0, nrcpts=44,
proto=ESMTP, daemon=MTA, relay=loopback [127.0.0.1]

-Patrick



[log in to unmask] wrote:

>On Thu, 26 Sep 2002 11:56:15 EDT, Patrick Price <[log in to unmask]>  said:
>
>>Should I be concerned about these?
>>
>>Sep 26 11:50:59 bugs sendmail[34894]: g8QFndhQ034894: lost input channel
>>from loopback [127.0.0.1] to MTA after rcpt
>>
>
>Aha.
>
>These are probably the *OTHER* end of the listserv-sendmail connection
>going away after the 'resource temporarily unavailable' error.  The fact
>that the number of hits *increased* when you tweaked SMTP_FORWARD_1 indicates
>that whatever is happening is doing so at a fairly low level.
>
>I admit being at a loss for what resource could run out after the RCPT TO:,
>but I'm feeling pretty confident that the problem is that the LSV side starts
>sending the mail, gets into the RCPT TO phase, runs out of "something",
>and closes the connection.  Lather, rinse, repeat.
>
>Could you take one of those queue id's ( g8QFrghQ031672 for example) and
>grep for *all* occurences in your sendmail log?  I'm curious about how many
>recipients were listed, and exactly how far (and how fast) it got to the
>point it died...
>