Thu, 26 Sep 2002 19:30:47 -0400
|
It looks like 1.8e is dropping emails each time this happens. This is
how my /spool filled up before leading to overall delivery delays.
Sep 26 18:39:26 bugs sendmail[31966]: g8QK7xdC031966: lost input channel
from bugs.systems.wvu.edu [157.182.232.209] to MTA after rcpt
Sep 26 18:41:31 bugs sendmail[45148]: g8QMd6bm045148: lost input channel
from bugs.systems.wvu.edu [157.182.232.209] to MTA after rcpt
Sep 26 18:44:41 bugs sendmail[31862]: g8QMfBbs031862: lost input channel
from bugs.systems.wvu.edu [157.182.232.209] to MTA after rcpt
:/home/listserv/spool>ls -l
-
-rw-r--r-- 1 listserv staff 7359 Sep 26 18:38 100250.mail
-rw-r--r-- 1 listserv staff 5187 Sep 26 18:39 100253.mail
-rw-r--r-- 1 listserv staff 4979 Sep 26 18:43 100259.mail
-rw-r--r-- 1 listserv staff 6 Sep 26 16:03 listserv.PID
Valdis Kletnieks 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...
>--
> Valdis Kletnieks
> Computer Systems Senior Engineer
> Virginia Tech
>
>
|
|
|