After removing over 1000 stale .mail files from spool (I left 78 in there), I get this: 26 Sep 2002 13:44:18 LISTSERV(R) for unix version 1.8e starting... 26 Sep 2002 13:44:18 Copyright L-Soft international 1986-2002 26 Sep 2002 13:44:18 Requeuing 78 mail files for delivery... Receive error: Resource temporarily unavailable 26 Sep 2002 13:45:27 >>> Error X'00B0005B' enqueuing mail for delivery <<< 26 Sep 2002 13:45:27 -> Severity: Error 26 Sep 2002 13:45:27 -> Facility: POSIX/unix error codes 26 Sep 2002 13:45:27 -> Abstract: Unspecified error (11) - See errno.h 26 Sep 2002 13:45:27 -> strerror: Resource temporarily unavailable 26 Sep 2002 13:45:27 -> 78 mail files left unprocessed. 26 Sep 2002 13:45:27 SIGNUP files are being compressed... 26 Sep 2002 13:45:27 -> No entry removed. 26 Sep 2002 13:45:27 Building list indexes... Patrick Price West Virginia University 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 >