lists are sluggish (delays of up to 8 hours)


Status Graveyard
Server Operations
11 years ago
3 years ago


(Reporter: dbaron, Assigned: justdave)





11 years ago
This is similar to bug 372009, but I'm filing a new bug.  I probably should have noticed this before Damon mentioned it to me, since my 8AM moderation messages were coming through very late today (and maybe yesterday too).

Messages sent to lists on are taking a long time to get through.  Damon's message yesterday to dev-planning was stuck for 3 and a half hours before hitting mailman and another 4 and a quarter in mailman, as shown by the following *consecutive* headers:

Received: from (localhost.localdomain [])
        by (Postfix) with ESMTP id 7FE2B58057;
        Tue,  1 May 2007 01:39:50 -0700 (PDT)
Received: from ( [])
        by (Postfix) with ESMTP id AD29D5802E
        for <>;
        Mon, 30 Apr 2007 21:23:49 -0700 (PDT)
Received: from [] (
        []) (Authenticated sender:
        by (Postfix) with ESMTP id D0E716A8EF5
        for <>;
        Mon, 30 Apr 2007 17:54:17 -0700 (PDT)
Assignee: server-ops → justdave
Severity: major → critical
OS: Other → All
OK, turns out the existing cron job was still dealing adequately with the mime parse problem that I assumed was causing this.  The real cause this time was that the nameserver for seems to have dropped off the planet, and victory/maki/whatever his name is this week is on almost every list, and DNS lookups were killing it trying to process the outbound queue.  I did some fiddling with the DNS configuration in mailman and postfix so that the DNS lookups are deferred until after the messages are separated by destination in the postfix queue, and now we have 2300 messages in the postfix queue instead of the mailman queue (but the mail for everyone else is no longer delayed by waiting for lookups to time out)
Last Resolved: 11 years ago
Resolution: --- → FIXED
Product: → Graveyard
You need to log in before you can comment on or make changes to this bug.