delay between delivery to mailman post command and sending out to list
Hi,
I’m running Mailman version 2.1.14 on an Ubuntu 12.04.5 LTS build, with Postfix MTA.
I recently noticed up to one hour delays between Postfix delivering messages to command "/var/lib/mailman/mail/mailman post [listname]", and Mailman effectively sending out the message to list members (as evidenced in Postfix log file, email headers, and Mailman logs).
The delays are consistent in that each posted message, to any list and with any number of subscriptions (between 1 and 250), is delayed by at least 20 minutes.
The Mailman "post" log file /var/log/mailman/post does not indicate the message being posted, until the message is finally being sent out up to one hour after the post.
However, the list’s archives, as well as the list’s digest.mbox file, DO contain the posted message immediately after posting, confirming that Mailman did instantly receive the message from Postfix.
Similarly, email notifications to admin (new list, memberships, …) suffer from the same delays.
There are no errors found in the qrunner, mischief, or smtp log files that give pointers as to why this happens.
The system is not under any load to speak of, and Postfix is running fine otherwise, delivering mail to local users and remote recipients instantly. The mail queue is virtually empty.
Would running separate, verbose instances of qrunner possibly give me any insight, and how should I go about this? Any input is appreciated.
Regards,
Nicolas
On 07/26/2016 11:19 AM, Nicolas wrote:
The Mailman "post" log file /var/log/mailman/post does not indicate the message being posted, until the message is finally being sent out up to one hour after the post.
This is expected. It's not written until the message is sent.
However, the list’s archives, as well as the list’s digest.mbox file, DO contain the posted message immediately after posting, confirming that Mailman did instantly receive the message from Postfix.
Mailman's 'out' queue is backlogged. (I really need to write a FAQ on this <sigh>).
You can tell because of the above and there will be several files in Mailman's qfiles/out directory and the entries in Mailman's 'smtp' log will be continuous, i.e. the timestamps of each entry will be x seconds after the previous one where x is the "completed in n.nnn seconds" value.
Would running separate, verbose instances of qrunner possibly give me any insight, and how should I go about this? Any input is appreciated.
Multiple, sliced OutgoingRunner processes might help, but the real issue is it takes too long for Mailman to deliver to Postfix due to Postfix configuration. In my production installation with full VERP, Mailman delivers to about 20 or more recipients per second.
See <https://wiki.list.org/x/4030636>, although a lot of that is outdated, but do note all the stuff on disable_dns_lookups.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 27 Jul 2016, at 15:47, Mark Sapiro <mark@msapiro.net> wrote:
On 07/26/2016 11:19 AM, Nicolas wrote:
Would running separate, verbose instances of qrunner possibly give me any insight, and how should I go about this? Any input is appreciated.
Multiple, sliced OutgoingRunner processes might help, but the real issue is it takes too long for Mailman to deliver to Postfix due to Postfix configuration. In my production installation with full VERP, Mailman delivers to about 20 or more recipients per second.
See <https://wiki.list.org/x/4030636>, although a lot of that is outdated, but do note all the stuff on disable_dns_lookups.
After deleting a subscribed email address with a non-existing domain from a list without automatic bounce processing configured, for which Mailman obsessively retried delivery every minute while ignoring all the other queued posts, I see up to 50 deliveries per second.
Just to confirm (probably ad nauseam for the regulars out here) that a separate Postfix instance with dns lookups disabled (+ automatic bounce processing) is the way to go.
Thanks,
Nicolas
participants (2)
-
Mark Sapiro -
Nicolas