[Mailman-Developers] qrunner infinite loop?

[Greg Ward]

On 25 August 2003, Barry Warsaw said:
> OutgoingRunner should be fairly sane since all it's doing is reading the
> files from disk and spewing them over port 25 to your local smptd.  It's
> also doing logging so you could tail logs/{smtp,smtp-failure,post} to
> watch it make progress.  You should also see the qfiles/out directory
> grow and shrink as files are consumed and unlinked, or new ones are
> prepared for sending out.

At one point, Mailman was running for several hours, and it consumed
exactly as much CPU time as elapsed time since it was started.  Sounds
like an infinite loop to me.

It turns out that Mailman (or possibly Exim) were misconfigured on the
host in question (drydock.python.net, for context).  Mailman had been
configured to use "python2.net" for its email domain -- which is fine as
far as DNS is concerned, but Exim on that host was *not* told that
python2.net is one of its local domains.  Here's what might have
happened if Mailman had connected to Exim to send a message:

  mail from:<mailman-bounces-... at python2.net>
  250 OK
  rcpt to:<gward at python.net>
  451 Temporary local problem - please try later

Two glitches with that theory though:

  * I ran "tcpdump -i lo" while qrunner was in its infinite-looking
    loop, and there was no traffic -- so Mailman was apparently not
    connecting to Exim

  * between the "rcpt to" and the 451 is a noticeable delay --
    between 0.5 and 1.0 sec I would say.  Not sure what Exim is doing
    there (maybe DNS is slow on this host?), but qrunner should
    not be consuming CPU while waiting for Exim's 451.

Anyways, I fixed Mailman's configuration and deleted qfiles/*/*, and now
qrunner runs happily.  Well, it least it doesn't suck CPU.  And I have a
clue how to reproduce this problem in case anyone cares to give it a
shot.

        Greg
-- 
Greg Ward <gward at python.net>                         http://www.gerg.ca/
Condense soup, not books!