Hi all,
I'm running into an issue with Mailman 3. Mails sent to a list are being held due to moderation settings — which is expected — but after approving them, they are not delivered to list members.
The message does not end up in the shunt queue, and nothing is delivered.
Here's what I see in the Mailman log:
Jul 30 16:12:23 2025 (213300) HOLD: mm@lists.example.com post from sender@sub.example.com held, message-id=<20250730141221.5VVrn%sender@sub.example.com>: The message is not from a list member Jul 30 16:12:39 2025 (213338) held message approved, message-id: <20250730141221.5VVrn%sender@sub.example.com>
In the mail log, I only see the message arriving — there's no sign of it being sent out.
Any ideas on what could be going wrong or where else I should look?
Mailman Core-Version GNU Mailman 3.3.10 (Tom Sawyer) Mailman Core API-Version 3.1 Mailman Core Python-Version 3.11.11 (main, Jun 20 2025, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-5)]
OS: Rocky 9 with Postfix MTA, installed as venv
Thanks in advance Stephan
On Wed, Jul 30, 2025 at 5:28 PM Stephan Krinetzki < krinetzki@itc.rwth-aachen.de> wrote:
Hi all,
I'm running into an issue with Mailman 3. Mails sent to a list are being held due to moderation settings — which is expected — but after approving them, they are not delivered to list members.
The message does not end up in the shunt queue, and nothing is delivered.
Here's what I see in the Mailman log:
Jul 30 16:12:23 2025 (213300) HOLD: mm@lists.example.com post from sender@sub.example.com held, message-id=< 20250730141221.5VVrn%sender@sub.example.com>: The message is not from a list member Jul 30 16:12:39 2025 (213338) held message approved, message-id: < 20250730141221.5VVrn%sender@sub.example.com>
In the mail log, I only see the message arriving — there's no sign of it being sent out.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This here does not make sense. the queue?
- You approve/UNHOLD the message - what then do you see in /opt/mailman/mm/var/logs/smtp.log?
- The mail is handed over to your MTA, and you see evidence of that in mail.log, but it is not sent out. Doesn't that mean you have the mails in
Any ideas on what could be going wrong or where else I should look?
What is the output from running the mailq command?
If the post has not reached the subscribers, then I suppose the emails are
stuck in the Postfix queue for some reason.
Mailman Core-Version GNU Mailman 3.3.10 (Tom Sawyer) Mailman Core API-Version 3.1 Mailman Core Python-Version 3.11.11 (main, Jun 20 2025, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-5)]
OS: Rocky 9 with Postfix MTA, installed as venv
Do you know if the list has been working, or is this a new install?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
On 7/30/25 07:27, Stephan Krinetzki wrote:
Hi all,
I'm running into an issue with Mailman 3. Mails sent to a list are being held due to moderation settings — which is expected — but after approving them, they are not delivered to list members. Are there any regular members with delivery enabled?
mailman members --regular --nomail enabled LISTSPEC
The message does not end up in the shunt queue, and nothing is delivered.
Here's what I see in the Mailman log:
Jul 30 16:12:23 2025 (213300) HOLD: mm@lists.example.com post from sender@sub.example.com held, message-id=<20250730141221.5VVrn%sender@sub.example.com>: The message is not from a list member Jul 30 16:12:39 2025 (213338) held message approved, message-id: <20250730141221.5VVrn%sender@sub.example.com>
This is expected. Is there anything relevant in Mailman's smtp.log?
Do any posts to this list get delivered, e.g., posts which aren't held.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
After accepting the message the smtp.log doesn't show any sign of further processing. Other mailinglists on the same host are doing fine. Even a 1:1 copy of the list works - only the original list does not work. Evene after deleting and recreating the list the error persists. The maillog oft the host only shows the incoming mail, but not the outgoing. The mail seems to vanish after accepting.
mailman members --regular --nomail enabled LISTSPEC
Shows a lot of addresses - so all the members of the list don't recieve an mail, which explains the vanished mail. Next step: Enable the the mailing for them.
Well..after checking the API, there are no Users with nomail. So the mail should be send.
Stephan Krinetzki writes:
Well..after checking the API, there are no Users with nomail. So the mail should be send.
- You mentioned checking the shunt queue. Have you checked the bad queue, and all the other queues for good measure?
- If archiving is enabled, are the messages being archived?
- Even though there's nothing in smtp.log, you should still check mailq for held mail (there may be related issues).
Mailman operates on the traditional "store and forward" principle. That is, unless an explicit decision is made to discard a message, Mailman will not discard the qfile until all destinations (usually the local MTA, archiver, and possibly news gateway) have accepted responsibility for further delivery. There's a pretty good chance that evidence of what happened is in either the Mailman or MTA queues.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
My queues:
ls -al /opt/mailman/var/queue/* /opt/mailman/var/queue/archive: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/bad: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 10:18 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/bounces: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/command: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:17 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/digest: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:15 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/in: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/nntp: total 0 drwxrwx--- 2 mailman mailman 6 Jun 27 2024 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/out: total 2868 drwxrwx--- 2 mailman mailman 4096 Jul 31 13:26 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 221708 Jul 30 13:16 1753874180.0845337+0cc7849043859a79dc3678a0d8b63c1c66df0c66.pck.tmp -rw-rw---- 1 mailman mailman 733425 Jul 31 00:00 1753912841.8847518+da55f8789ae41b75d19a02b595e3fd6d45983ade.pck.tmp -rw-rw---- 1 mailman mailman 17758 Jul 31 13:26 1753961185.0481033+6adf966467266567275f1146f5054c95e4365c13.pck -rw-rw---- 1 mailman mailman 31122 Jul 31 13:26 1753961185.1064982+b1f502e2af56b9b11680135c6de5fcc5285d967e.bak -rw-rw---- 1 mailman mailman 12945 Jul 31 13:26 1753961185.1562705+a88534cfa9b03012c248ac00cbb54f4fc08c8dcc.pck -rw-rw---- 1 mailman mailman 1407634 Jul 31 13:26 1753961185.2598634+96e501d7aa8e72fbb9f9a5c953d48fc2c7db2bc7.pck -rw-rw---- 1 mailman mailman 17570 Jul 31 13:26 1753961185.3654013+d693065f2b9a2338f887d3ac9c0669c957131100.pck -rw-rw---- 1 mailman mailman 60624 Jul 31 13:26 1753961185.4132354+8998ee9eb9a8a99faf1fcf045d604e669f5d0c9e.pck -rw-rw---- 1 mailman mailman 7361 Jul 31 13:26 1753961185.413462+50dcef9bb178f54ecb2d4707ccfe02773f92336c.pck -rw-rw---- 1 mailman mailman 84848 Jul 31 13:26 1753961185.4464717+17836b8875aa6643f7e5fb0744e72940ce5603c6.pck -rw-rw---- 1 mailman mailman 18003 Jul 31 13:26 1753961185.4929028+17e9c78a2721cbc344124c6e04a129217ea6c794.pck -rw-rw---- 1 mailman mailman 66982 Jul 31 13:26 1753961185.5228019+4ef59e61c6a79dd4cdee6d1110fb0582fcfafb6c.pck -rw-rw---- 1 mailman mailman 221723 Jul 31 13:26 1753961185.5756643+6de90ae99b3d528ce5234b78a287e19f7b6686fc.pck
/opt/mailman/var/queue/pipeline: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/retry: total 0 drwxrwx--- 2 mailman mailman 6 Feb 18 08:57 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/shunt: total 3304 drwxrwx--- 2 mailman mailman 4096 Jul 31 11:44 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 451 Jul 31 00:00 1753912822.2651796+28eceef7e18eb70393377b88dc7117af8f9362a0.pck -rw-rw---- 1 mailman mailman 490 Jul 31 00:00 1753912838.4197352+ea531cf0262c1faa58b1679b907fee92bc16822c.pck -rw-rw---- 1 mailman mailman 1407870 Jul 31 00:00 1753912841.9177196+ccea15bdefce3a54301281c8eddf86e8230244a6.pck -rw-rw---- 1 mailman mailman 86108 Jul 31 00:00 1753912841.9197443+7dcef4febc71e44c6d9309a24a08b08753e1ff42.pck -rw-rw---- 1 mailman mailman 1407668 Jul 31 00:00 1753912841.9849963+a3f1869b750060c97262ece38737480d91652828.pck -rw-rw---- 1 mailman mailman 38992 Jul 31 00:01 1753912860.5167956+940584c4f361cbd8c29e390b2f60590558effe40.pck -rw-rw---- 1 mailman mailman 440 Jul 31 00:01 1753912860.6972685+635c065bac8dff5f9d562275d707001d773b84c1.pck -rw-rw---- 1 mailman mailman 445 Jul 31 00:01 1753912868.7903054+befa066f254d7a3529a8555a6c942a554715d837.pck -rw-rw---- 1 mailman mailman 33494 Jul 31 00:01 1753912878.7562895+82b724fd93260ab9a2bb49709d3a42a2f32f2c80.pck -rw-rw---- 1 mailman mailman 217073 Jul 31 00:01 1753912878.9337828+de73a65d9c6febfa80275853921f4b53fd1d9e2a.pck -rw-rw---- 1 mailman mailman 85888 Jul 31 00:02 1753912950.303359+8a87bce0be63ac1df8493c6b1ad6ae154fcedba7.pck -rw-rw---- 1 mailman mailman 50244 Jul 31 00:02 1753912950.4970112+d44d493912bb3024547b8a5112f86f035dcb352f.pck -rw-rw---- 1 mailman mailman 12887 Jul 31 00:02 1753912970.038427+31bcbd7fb2ebdf81f6de24b7283b50bcda6ded21.pck.tmp -rw-rw---- 1 mailman mailman 443 Jul 31 11:44 1753955094.900898+67bc76525412da66a7c76363f65f583989716305.pck
/opt/mailman/var/queue/virgin: total 32 drwxrwx--- 2 mailman mailman 81 Jul 31 13:17 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 32013 Jan 11 2025 1736550035.6163204+472f81ece5e45a2651a4499bef418f611b43c619.pck.tmp
Nothing special there (shunt should be checked, but not in correlation with my mail).
I have one list which archives the mail. In the archive there is the mail, but it doesn't get deliverd
mailq is empty, so my postfix works as expected.
An other ideas?
On Thu, Jul 31, 2025 at 2:30 PM Stephan Krinetzki < krinetzki@itc.rwth-aachen.de> wrote:
My queues:
ls -al /opt/mailman/var/queue/* /opt/mailman/var/queue/archive: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/bad: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 10:18 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/bounces: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/command: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:17 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/digest: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:15 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/in: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/nntp: total 0 drwxrwx--- 2 mailman mailman 6 Jun 27 2024 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/out: total 2868 drwxrwx--- 2 mailman mailman 4096 Jul 31 13:26 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 221708 Jul 30 13:16 1753874180.0845337+0cc7849043859a79dc3678a0d8b63c1c66df0c66.pck.tmp -rw-rw---- 1 mailman mailman 733425 Jul 31 00:00 1753912841.8847518+da55f8789ae41b75d19a02b595e3fd6d45983ade.pck.tmp -rw-rw---- 1 mailman mailman 17758 Jul 31 13:26 1753961185.0481033+6adf966467266567275f1146f5054c95e4365c13.pck -rw-rw---- 1 mailman mailman 31122 Jul 31 13:26 1753961185.1064982+b1f502e2af56b9b11680135c6de5fcc5285d967e.bak -rw-rw---- 1 mailman mailman 12945 Jul 31 13:26 1753961185.1562705+a88534cfa9b03012c248ac00cbb54f4fc08c8dcc.pck -rw-rw---- 1 mailman mailman 1407634 Jul 31 13:26 1753961185.2598634+96e501d7aa8e72fbb9f9a5c953d48fc2c7db2bc7.pck -rw-rw---- 1 mailman mailman 17570 Jul 31 13:26 1753961185.3654013+d693065f2b9a2338f887d3ac9c0669c957131100.pck -rw-rw---- 1 mailman mailman 60624 Jul 31 13:26 1753961185.4132354+8998ee9eb9a8a99faf1fcf045d604e669f5d0c9e.pck -rw-rw---- 1 mailman mailman 7361 Jul 31 13:26 1753961185.413462+50dcef9bb178f54ecb2d4707ccfe02773f92336c.pck -rw-rw---- 1 mailman mailman 84848 Jul 31 13:26 1753961185.4464717+17836b8875aa6643f7e5fb0744e72940ce5603c6.pck -rw-rw---- 1 mailman mailman 18003 Jul 31 13:26 1753961185.4929028+17e9c78a2721cbc344124c6e04a129217ea6c794.pck -rw-rw---- 1 mailman mailman 66982 Jul 31 13:26 1753961185.5228019+4ef59e61c6a79dd4cdee6d1110fb0582fcfafb6c.pck -rw-rw---- 1 mailman mailman 221723 Jul 31 13:26 1753961185.5756643+6de90ae99b3d528ce5234b78a287e19f7b6686fc.pck
/opt/mailman/var/queue/pipeline: total 0 drwxrwx--- 2 mailman mailman 6 Jul 31 13:20 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/retry: total 0 drwxrwx--- 2 mailman mailman 6 Feb 18 08:57 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 ..
/opt/mailman/var/queue/shunt: total 3304 drwxrwx--- 2 mailman mailman 4096 Jul 31 11:44 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 451 Jul 31 00:00 1753912822.2651796+28eceef7e18eb70393377b88dc7117af8f9362a0.pck -rw-rw---- 1 mailman mailman 490 Jul 31 00:00 1753912838.4197352+ea531cf0262c1faa58b1679b907fee92bc16822c.pck -rw-rw---- 1 mailman mailman 1407870 Jul 31 00:00 1753912841.9177196+ccea15bdefce3a54301281c8eddf86e8230244a6.pck -rw-rw---- 1 mailman mailman 86108 Jul 31 00:00 1753912841.9197443+7dcef4febc71e44c6d9309a24a08b08753e1ff42.pck -rw-rw---- 1 mailman mailman 1407668 Jul 31 00:00 1753912841.9849963+a3f1869b750060c97262ece38737480d91652828.pck -rw-rw---- 1 mailman mailman 38992 Jul 31 00:01 1753912860.5167956+940584c4f361cbd8c29e390b2f60590558effe40.pck -rw-rw---- 1 mailman mailman 440 Jul 31 00:01 1753912860.6972685+635c065bac8dff5f9d562275d707001d773b84c1.pck -rw-rw---- 1 mailman mailman 445 Jul 31 00:01 1753912868.7903054+befa066f254d7a3529a8555a6c942a554715d837.pck -rw-rw---- 1 mailman mailman 33494 Jul 31 00:01 1753912878.7562895+82b724fd93260ab9a2bb49709d3a42a2f32f2c80.pck -rw-rw---- 1 mailman mailman 217073 Jul 31 00:01 1753912878.9337828+de73a65d9c6febfa80275853921f4b53fd1d9e2a.pck -rw-rw---- 1 mailman mailman 85888 Jul 31 00:02 1753912950.303359+8a87bce0be63ac1df8493c6b1ad6ae154fcedba7.pck -rw-rw---- 1 mailman mailman 50244 Jul 31 00:02 1753912950.4970112+d44d493912bb3024547b8a5112f86f035dcb352f.pck -rw-rw---- 1 mailman mailman 12887 Jul 31 00:02 1753912970.038427+31bcbd7fb2ebdf81f6de24b7283b50bcda6ded21.pck.tmp -rw-rw---- 1 mailman mailman 443 Jul 31 11:44 1753955094.900898+67bc76525412da66a7c76363f65f583989716305.pck
/opt/mailman/var/queue/virgin: total 32 drwxrwx--- 2 mailman mailman 81 Jul 31 13:17 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 32013 Jan 11 2025 1736550035.6163204+472f81ece5e45a2651a4499bef418f611b43c619.pck.tmp
Nothing special there (shunt should be checked, but not in correlation with my mail).
I have one list which archives the mail. In the archive there is the mail, but it doesn't get deliverd
How many subscribers do you have on this list? And you said their "Delivery Status" is set to "Enabled"??
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
On the current list there were about 43000 Subscribers.
And the "Delivery Status" of the members is enabled. Via REST API:
{"address": "http://localhost:8001/3.1/addresses/user@example.com", "bounce_score": 0, "last_warning_sent": "0001-01-01T00:00:00", "total_warnings_sent": 0, "delivery_mode": "regular", "email": "user@example.com", "list_id": "users.lists.example.com", "subscription_mode": "as_address", "role": "member", "user": "http://localhost:8001/3.1/users/c108f28ca58c450ea2c2a91e56b79a3a", "display_name": "", "self_link": "http://localhost:8001/3.1/members/4529b34a6977481b8f9f33efe6e6aa35", "member_id": "4529b34a6977481b8f9f33efe6e6aa35", "http_etag": "\"d36844a7a58a87880efa4f84c90ae3c90df38e29\""}
On another list with the same problem are 63 subscribers.
On 7/31/25 04:29, Stephan Krinetzki wrote:
/opt/mailman/var/queue/out: total 2868 drwxrwx--- 2 mailman mailman 4096 Jul 31 13:26 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 221708 Jul 30 13:16 1753874180.0845337+0cc7849043859a79dc3678a0d8b63c1c66df0c66.pck.tmp -rw-rw---- 1 mailman mailman 733425 Jul 31 00:00 1753912841.8847518+da55f8789ae41b75d19a02b595e3fd6d45983ade.pck.tmp
These indicate a problem of some sort. .pck.tmp files should only exist for a fraction of a second. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/switchboar...
What does `mailman qfile report for these? Are they the missing messages?
-rw-rw---- 1 mailman mailman 17758 Jul 31 13:26 1753961185.0481033+6adf966467266567275f1146f5054c95e4365c13.pck -rw-rw---- 1 mailman mailman 31122 Jul 31 13:26 1753961185.1064982+b1f502e2af56b9b11680135c6de5fcc5285d967e.bak -rw-rw---- 1 mailman mailman 12945 Jul 31 13:26 1753961185.1562705+a88534cfa9b03012c248ac00cbb54f4fc08c8dcc.pck -rw-rw---- 1 mailman mailman 1407634 Jul 31 13:26 1753961185.2598634+96e501d7aa8e72fbb9f9a5c953d48fc2c7db2bc7.pck -rw-rw---- 1 mailman mailman 17570 Jul 31 13:26 1753961185.3654013+d693065f2b9a2338f887d3ac9c0669c957131100.pck -rw-rw---- 1 mailman mailman 60624 Jul 31 13:26 1753961185.4132354+8998ee9eb9a8a99faf1fcf045d604e669f5d0c9e.pck -rw-rw---- 1 mailman mailman 7361 Jul 31 13:26 1753961185.413462+50dcef9bb178f54ecb2d4707ccfe02773f92336c.pck -rw-rw---- 1 mailman mailman 84848 Jul 31 13:26 1753961185.4464717+17836b8875aa6643f7e5fb0744e72940ce5603c6.pck -rw-rw---- 1 mailman mailman 18003 Jul 31 13:26 1753961185.4929028+17e9c78a2721cbc344124c6e04a129217ea6c794.pck -rw-rw---- 1 mailman mailman 66982 Jul 31 13:26 1753961185.5228019+4ef59e61c6a79dd4cdee6d1110fb0582fcfafb6c.pck -rw-rw---- 1 mailman mailman 221723 Jul 31 13:26 1753961185.5756643+6de90ae99b3d528ce5234b78a287e19f7b6686fc.pck
Also, this is a lot of outgoing messages to be queued. Are you sending
periodic digests at this time? If you normally see a lot of messages in
the out queue, you might consider setting it's instances to 2 or 4. E.g.,
[runner.out]
instances: 4
in mailman.cfg
/opt/mailman/var/queue/shunt: total 3304 drwxrwx--- 2 mailman mailman 4096 Jul 31 11:44 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 451 Jul 31 00:00 1753912822.2651796+28eceef7e18eb70393377b88dc7117af8f9362a0.pck -rw-rw---- 1 mailman mailman 490 Jul 31 00:00 1753912838.4197352+ea531cf0262c1faa58b1679b907fee92bc16822c.pck -rw-rw---- 1 mailman mailman 1407870 Jul 31 00:00 1753912841.9177196+ccea15bdefce3a54301281c8eddf86e8230244a6.pck -rw-rw---- 1 mailman mailman 86108 Jul 31 00:00 1753912841.9197443+7dcef4febc71e44c6d9309a24a08b08753e1ff42.pck -rw-rw---- 1 mailman mailman 1407668 Jul 31 00:00 1753912841.9849963+a3f1869b750060c97262ece38737480d91652828.pck -rw-rw---- 1 mailman mailman 38992 Jul 31 00:01 1753912860.5167956+940584c4f361cbd8c29e390b2f60590558effe40.pck -rw-rw---- 1 mailman mailman 440 Jul 31 00:01 1753912860.6972685+635c065bac8dff5f9d562275d707001d773b84c1.pck -rw-rw---- 1 mailman mailman 445 Jul 31 00:01 1753912868.7903054+befa066f254d7a3529a8555a6c942a554715d837.pck -rw-rw---- 1 mailman mailman 33494 Jul 31 00:01 1753912878.7562895+82b724fd93260ab9a2bb49709d3a42a2f32f2c80.pck -rw-rw---- 1 mailman mailman 217073 Jul 31 00:01 1753912878.9337828+de73a65d9c6febfa80275853921f4b53fd1d9e2a.pck -rw-rw---- 1 mailman mailman 85888 Jul 31 00:02 1753912950.303359+8a87bce0be63ac1df8493c6b1ad6ae154fcedba7.pck -rw-rw---- 1 mailman mailman 50244 Jul 31 00:02 1753912950.4970112+d44d493912bb3024547b8a5112f86f035dcb352f.pck -rw-rw---- 1 mailman mailman 12887 Jul 31 00:02 1753912970.038427+31bcbd7fb2ebdf81f6de24b7283b50bcda6ded21.pck.tmp -rw-rw---- 1 mailman mailman 443 Jul 31 11:44 1753955094.900898+67bc76525412da66a7c76363f65f583989716305.pck
/opt/mailman/var/queue/virgin: total 32 drwxrwx--- 2 mailman mailman 81 Jul 31 13:17 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 32013 Jan 11 2025 1736550035.6163204+472f81ece5e45a2651a4499bef418f611b43c619.pck.tmp
Nothing special there (shunt should be checked, but not in correlation with my mail).
Actually those .pck.tmp files indicate some issue.
I have one list which archives the mail. In the archive there is the mail, but it doesn't get deliverd
Which says the pipeline to_archive handler is adding the message to the archive queue and the archive runner is handling it, so presumably the pipeline to_outgoing handler is adding the message to the out queue, so the issue is in the outging runner.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, Jul 31, 2025 at 8:21 PM Mark Sapiro <mark@msapiro.net> wrote:
On 7/31/25 04:29, Stephan Krinetzki wrote:
/opt/mailman/var/queue/out: total 2868 drwxrwx--- 2 mailman mailman 4096 Jul 31 13:26 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 221708 Jul 30 13:16
1753874180.0845337+0cc7849043859a79dc3678a0d8b63c1c66df0c66.pck.tmp
-rw-rw---- 1 mailman mailman 733425 Jul 31 00:00 1753912841.8847518+da55f8789ae41b75d19a02b595e3fd6d45983ade.pck.tmp
These indicate a problem of some sort. .pck.tmp files should only exist for a fraction of a second. See
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/switchboar...
What does `mailman qfile report for these? Are they the missing messages?
-rw-rw---- 1 mailman mailman 17758 Jul 31 13:26 1753961185.0481033+6adf966467266567275f1146f5054c95e4365c13.pck -rw-rw---- 1 mailman mailman 31122 Jul 31 13:26 1753961185.1064982+b1f502e2af56b9b11680135c6de5fcc5285d967e.bak -rw-rw---- 1 mailman mailman 12945 Jul 31 13:26 1753961185.1562705+a88534cfa9b03012c248ac00cbb54f4fc08c8dcc.pck -rw-rw---- 1 mailman mailman 1407634 Jul 31 13:26 1753961185.2598634+96e501d7aa8e72fbb9f9a5c953d48fc2c7db2bc7.pck -rw-rw---- 1 mailman mailman 17570 Jul 31 13:26 1753961185.3654013+d693065f2b9a2338f887d3ac9c0669c957131100.pck -rw-rw---- 1 mailman mailman 60624 Jul 31 13:26 1753961185.4132354+8998ee9eb9a8a99faf1fcf045d604e669f5d0c9e.pck -rw-rw---- 1 mailman mailman 7361 Jul 31 13:26 1753961185.413462+50dcef9bb178f54ecb2d4707ccfe02773f92336c.pck -rw-rw---- 1 mailman mailman 84848 Jul 31 13:26 1753961185.4464717+17836b8875aa6643f7e5fb0744e72940ce5603c6.pck -rw-rw---- 1 mailman mailman 18003 Jul 31 13:26 1753961185.4929028+17e9c78a2721cbc344124c6e04a129217ea6c794.pck -rw-rw---- 1 mailman mailman 66982 Jul 31 13:26 1753961185.5228019+4ef59e61c6a79dd4cdee6d1110fb0582fcfafb6c.pck -rw-rw---- 1 mailman mailman 221723 Jul 31 13:26 1753961185.5756643+6de90ae99b3d528ce5234b78a287e19f7b6686fc.pck
Also, this is a lot of outgoing messages to be queued. Are you sending periodic digests at this time? If you normally see a lot of messages in the out queue, you might consider setting it's
instancesto 2 or 4. E.g.,[runner.out] instances: 4in mailman.cfg
/opt/mailman/var/queue/shunt: total 3304 drwxrwx--- 2 mailman mailman 4096 Jul 31 11:44 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 451 Jul 31 00:00 1753912822.2651796+28eceef7e18eb70393377b88dc7117af8f9362a0.pck -rw-rw---- 1 mailman mailman 490 Jul 31 00:00 1753912838.4197352+ea531cf0262c1faa58b1679b907fee92bc16822c.pck -rw-rw---- 1 mailman mailman 1407870 Jul 31 00:00 1753912841.9177196+ccea15bdefce3a54301281c8eddf86e8230244a6.pck -rw-rw---- 1 mailman mailman 86108 Jul 31 00:00 1753912841.9197443+7dcef4febc71e44c6d9309a24a08b08753e1ff42.pck -rw-rw---- 1 mailman mailman 1407668 Jul 31 00:00 1753912841.9849963+a3f1869b750060c97262ece38737480d91652828.pck -rw-rw---- 1 mailman mailman 38992 Jul 31 00:01 1753912860.5167956+940584c4f361cbd8c29e390b2f60590558effe40.pck -rw-rw---- 1 mailman mailman 440 Jul 31 00:01 1753912860.6972685+635c065bac8dff5f9d562275d707001d773b84c1.pck -rw-rw---- 1 mailman mailman 445 Jul 31 00:01 1753912868.7903054+befa066f254d7a3529a8555a6c942a554715d837.pck -rw-rw---- 1 mailman mailman 33494 Jul 31 00:01 1753912878.7562895+82b724fd93260ab9a2bb49709d3a42a2f32f2c80.pck -rw-rw---- 1 mailman mailman 217073 Jul 31 00:01 1753912878.9337828+de73a65d9c6febfa80275853921f4b53fd1d9e2a.pck -rw-rw---- 1 mailman mailman 85888 Jul 31 00:02 1753912950.303359+8a87bce0be63ac1df8493c6b1ad6ae154fcedba7.pck -rw-rw---- 1 mailman mailman 50244 Jul 31 00:02 1753912950.4970112+d44d493912bb3024547b8a5112f86f035dcb352f.pck -rw-rw---- 1 mailman mailman 12887 Jul 31 00:02 1753912970.038427+31bcbd7fb2ebdf81f6de24b7283b50bcda6ded21.pck.tmp -rw-rw---- 1 mailman mailman 443 Jul 31 11:44 1753955094.900898+67bc76525412da66a7c76363f65f583989716305.pck
/opt/mailman/var/queue/virgin: total 32 drwxrwx--- 2 mailman mailman 81 Jul 31 13:17 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 32013 Jan 11 2025 1736550035.6163204+472f81ece5e45a2651a4499bef418f611b43c619.pck.tmp
Nothing special there (shunt should be checked, but not in correlation with my mail).
Actually those .pck.tmp files indicate some issue.
I have one list which archives the mail. In the archive there is the mail, but it doesn't get deliverd
Which says the pipeline to_archive handler is adding the message to the archive queue and the archive runner is handling it, so presumably the pipeline to_outgoing handler is adding the message to the out queue, so the issue is in the outging runner.
In one response, he mentioned that "Other mailinglists on the same host are doing fine. Even a 1:1 copy of the list works - only the original list does not work". Does it mean that "the issue is in the outgoing runner" only for a single list?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
On 7/31/25 10:38, Odhiambo Washington via Mailman-users wrote:
In one response, he mentioned that "Other mailinglists on the same host are doing fine. Even a 1:1 copy of the list works - only the original list does not work". Does it mean that "the issue is in the outgoing runner" only for a single list?
So far we have not determined what the issue is. Until we do, we don't know in which module it is. It could be in outgoing runner involving something in the list's configuration or membership that isn't in the "1:1 copy" or it could be something to do with the message itself. It could even be an OS error such as "out of memory" due to the large number of list members.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
On 7/31/25 04:29, Stephan Krinetzki wrote:
I have one list which archives the mail. In the archive there is the mail, but it doesn't get deliverdWhich says the pipeline to_archive handler is adding the message to the archive queue and the archive runner is handling it, so presumably the pipeline to_outgoing handler is adding the message to the out queue, so the issue is in the outging runner.
Actually, there's more involved in the pipeline between the to_archive and to_outgoing handlers. The to-digest, to-usenet, after-delivery, acknowledge and dmarc handlers are all invoked between to_archive and to_outgoing
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I see Mark answered some of the same questions already, but it would be really painstaking to avoid duplication (it took more than an hour to write this :-), so I'm just gonna scan it quickly and then send.
Stephan Krinetzki writes:
My queues:
(Omitting the empty ones.)
/opt/mailman/var/queue/out: total 2868 drwxrwx--- 2 mailman mailman 4096 Jul 31 13:26 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 221708 Jul 30 13:16 1753874180.0845337+0cc7849043859a79dc3678a0d8b63c1c66df0c66.pck.tmp -rw-rw---- 1 mailman mailman 733425 Jul 31 00:00 1753912841.8847518+da55f8789ae41b75d19a02b595e3fd6d45983ade.pck.tmp -rw-rw---- 1 mailman mailman 17758 Jul 31 13:26 1753961185.0481033+6adf966467266567275f1146f5054c95e4365c13.pck
Those two .pck.tmp files are bad news. They indicate that Mailman was trying to do something with those messages, and the process was interrupted. You should check whether there was a Mailman restart at those times (although it should shutdown gracefully and not leave .tmp files behind), or if a runner crashed.
The .tmp files *may* be deliverable, but you'd have to look at them to be sure that they are complete. It's possible that they have been delivered already and the .tmp files just need to be removed. You can look at them with "mailman qfile" same as always, "qfile" doesn't check the filename extension. If they haven't been delivered and a careful check shows they're intact, just renaming without the .tmp will cause them to go to the head of the queue.
It's also odd that the .pck above precedes the ,bak below (unless you have multiple slices for the out queue?)
The rest of the queue looks normal, except that it seems rather long. I only see queues that long when the outgoing MTA is borked. (Although my experience with high-traffic systems is restricted to helping a couple of folks for whom there was zero cost to adding CPUs and memory to their VMs, I feel better that Mark picked up on this too.) You might want to reconfigure Mailman to use more out slices, but that depends on what else your MTA should be using its bandwidth for. Because of the way the slicing algorithm works, the number of slices needs to be a power of 2, so the number of simultaneous connections Mailman makes to the MTA will double. (I don't think there's any point to more than 4 slices unless you're doing more than one incoming post/second.)
-rw-rw---- 1 mailman mailman 31122 Jul 31 13:26 1753961185.1064982+b1f502e2af56b9b11680135c6de5fcc5285d967e.bak
This .bak file is currently being processed by Mailman, it's normal. The rest of the .pck files are also normal, just waiting. (Omitting the rest of the out queue listing.)
/opt/mailman/var/queue/shunt: total 3304 drwxrwx--- 2 mailman mailman 4096 Jul 31 11:44 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 451 Jul 31 00:00 1753912822.2651796+28eceef7e18eb70393377b88dc7117af8f9362a0.pck -rw-rw---- 1 mailman mailman 490 Jul 31 00:00 1753912838.4197352+ea531cf0262c1faa58b1679b907fee92bc16822c.pck -rw-rw---- 1 mailman mailman 1407870 Jul 31 00:00 1753912841.9177196+ccea15bdefce3a54301281c8eddf86e8230244a6.pck -rw-rw---- 1 mailman mailman 86108 Jul 31 00:00 1753912841.9197443+7dcef4febc71e44c6d9309a24a08b08753e1ff42.pck -rw-rw---- 1 mailman mailman 1407668 Jul 31 00:00 1753912841.9849963+a3f1869b750060c97262ece38737480d91652828.pck -rw-rw---- 1 mailman mailman 38992 Jul 31 00:01 1753912860.5167956+940584c4f361cbd8c29e390b2f60590558effe40.pck -rw-rw---- 1 mailman mailman 440 Jul 31 00:01 1753912860.6972685+635c065bac8dff5f9d562275d707001d773b84c1.pck -rw-rw---- 1 mailman mailman 445 Jul 31 00:01 1753912868.7903054+befa066f254d7a3529a8555a6c942a554715d837.pck -rw-rw---- 1 mailman mailman 33494 Jul 31 00:01 1753912878.7562895+82b724fd93260ab9a2bb49709d3a42a2f32f2c80.pck -rw-rw---- 1 mailman mailman 217073 Jul 31 00:01 1753912878.9337828+de73a65d9c6febfa80275853921f4b53fd1d9e2a.pck -rw-rw---- 1 mailman mailman 85888 Jul 31 00:02 1753912950.303359+8a87bce0be63ac1df8493c6b1ad6ae154fcedba7.pck -rw-rw---- 1 mailman mailman 50244 Jul 31 00:02 1753912950.4970112+d44d493912bb3024547b8a5112f86f035dcb352f.pck -rw-rw---- 1 mailman mailman 12887 Jul 31 00:02 1753912970.038427+31bcbd7fb2ebdf81f6de24b7283b50bcda6ded21.pck.tmp -rw-rw---- 1 mailman mailman 443 Jul 31 11:44 1753955094.900898+67bc76525412da66a7c76363f65f583989716305.pck
/opt/mailman/var/queue/virgin: total 32 drwxrwx--- 2 mailman mailman 81 Jul 31 13:17 . drwxr-xr-x 14 mailman mailman 165 Jun 27 2024 .. -rw-rw---- 1 mailman mailman 32013 Jan 11 2025 1736550035.6163204+472f81ece5e45a2651a4499bef418f611b43c619.pck.tmp
Nothing special there (shunt should be checked, but not in correlation with my mail).
I tend to disagree, as the first series of shunt files ends with a .tmp. There's another one of those .tmp files in virgin, and it's 6 months old. Hmmm, that one is *also* on the hour. You got lots of cron jobs that run on the hour, maybe?
You're probably right that there's no correlation, but you can't trust the dates from ls -l or stat because when running "mailman unshunt" all of the queue files in shunt will get "touched" if they're not sent. (If I recall correctly.) The fact that a spate of timestamps occur right at 00:00 means either there's a cron job running unshunt then, or you have a spammer or similar sending a bunch of broken mail to you on the hour. (I say you're probably right because the time stamp in the name decodes to the same time, and I don't think that changes when unshunt is run.) And again, you have a stale .tmp file there, which means something bad happened, most likely not under Mailman's control.
There is (maybe was. by now?) a bug in the logging such that logs did not get properly rotated. Many sites dealt with this by restarting Mailman with the same period of the log rotation. Do you do that? (I'm just fishing, I don't know how it could cause the main issue you are seeing.)
mailq is empty, so my postfix works as expected.
Hm. Those "high traffic" sites I mentioned, it was the other way around: with 4 (or 8) "out" slices, the out queue would be clear >80% of the time (according to "while 1; do ls -l $OUTQUEUE; sleep 5; done", nothing sophisticated). But the MTA's mail queue would typically backlog many minutes. As I said, the Mailman hosts at those sites were insanely overpowered, so your mileage will vary.
I have to think that there is a problem in the handoff between Mailman and the MTA. Why Mailman is not preserving the queuefile or alternatively logging a successful delivery to the MTA I don't have any idea off hand. I have to think the queue runner is crashing, but that doesn't explain why this happens only to certain lists.
Is Postfix delivering to the final destination itself, or does it pass on the messages to a smarthost? Is Mailman talking to the local MTA, or is it possibly talking to an MTA on a different node? I did have to diagnose a problem once where a system was misconfigured, and Mailman was talking not to the local Postfix but to a Postfix in a datacenter a megameter or so away! (That didn't lose any mail, but the connection would occasionally freeze and not time out, leading to a huge build up in the out queue.) Anyway, if Mailman isn't talking to an MTA with a <50ms ping time, you could try changing the configuration so it does.
I don't put much stock in any of the above ideas. I hope that you or somebody come up with better ones!
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
First: Thank you all for your input! I hope that we will get down to the root of the problem.
I've checked all cronjobs and there is no cronjob that starts at midnight. All jobs are running later. So i looked into /var/log/messages. The earliest entry there is
Jul 31 23:56:16 iris-s01 bash[324554]: Jul 31 23:56:16 2025 (324554) Starting new HTTPS connection (1): lists.example.com:443 Jul 31 23:56:16 iris-s01 bash[324553]: Jul 31 23:56:16 2025 (324553) Starting new HTTPS connection (1): lists.example.com:443 Jul 31 23:56:16 iris-s01 bash[324556]: Jul 31 23:56:16 2025 (324556) Starting new HTTPS connection (1): lists.example.com:443 Jul 31 23:56:16 iris-s01 bash[324554]: Jul 31 23:56:16 2025 (324554) Starting new HTTP connection (1): localhost:8000 Jul 31 23:56:16 iris-s01 bash[324553]: Jul 31 23:56:16 2025 (324553) Starting new HTTP connection (1): localhost:8000 Jul 31 23:56:16 iris-s01 bash[324556]: Jul 31 23:56:16 2025 (324556) Starting new HTTP connection (1): localhost:8000 Jul 31 23:56:16 iris-s01 bash[324554]: Jul 31 23:56:16 2025 (324554) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=rzcluster%40lists.example.com&msgid=c6140b6e649f46ee8a97aec5c5b80584%40sub.example.com HTTP/11" 200 126 Jul 31 23:56:16 iris-s01 bash[324553]: Jul 31 23:56:16 2025 (324553) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=ww10%40lists.example.com&msgid=1f86b244cce9479490b4bffe184f6c03%40sub.example.com HTTP/11" 200 121 Jul 31 23:56:16 iris-s01 bash[324554]: Jul 31 23:56:16 2025 (324554) Starting new HTTPS connection (1): lists.example.com:443 Jul 31 23:56:16 iris-s01 bash[324556]: Jul 31 23:56:16 2025 (324556) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=fg-informatik-ma-wiss%40lists.example.com&msgid=914dbace411247d7983b5dff8fa34bda%40i3.informatik.rwth-aachen.de HTTP/11" 200 138 Jul 31 23:56:16 iris-s01 bash[324553]: Jul 31 23:56:16 2025 (324553) Starting new HTTPS connection (1): lists.example.com:443 Jul 31 23:56:16 iris-s01 bash[324556]: Jul 31 23:56:16 2025 (324556) Starting new HTTPS connection (1): lists.example.com:443 Jul 31 23:56:16 iris-s01 bash[324553]: Jul 31 23:56:16 2025 (324553) Starting new HTTP connection (1): localhost:8000 Jul 31 23:56:16 iris-s01 bash[324553]: Jul 31 23:56:16 2025 (324553) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=ww10%40lists.example.com&msgid=bd99715d619744699ddf806fd3bd67b1%40sub.example.com HTTP/11" 200 121 Aug 1 00:02:48 iris-s01 bash[567713]: Aug 01 00:02:48 2025 (567713) Starting new HTTPS connection (1): lists.example.com:443 Aug 1 00:02:48 iris-s01 bash[567713]: Aug 01 00:02:48 2025 (567713) Starting new HTTP connection (1): localhost:8000 Aug 1 00:02:48 iris-s01 bash[567713]: Aug 01 00:02:48 2025 (567713) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=ww10%40lists.example.com&msgid=1f86b244cce9479490b4bffe184f6c03%40sub.example.com HTTP/11" 200 121 Aug 1 00:02:48 iris-s01 bash[567713]: Aug 01 00:02:48 2025 (567713) Starting new HTTPS connection (1): lists.example.com:443 Aug 1 00:02:48 iris-s01 bash[567715]: Aug 01 00:02:48 2025 (567715) Starting new HTTP connection (1): localhost:8000 Aug 1 00:02:48 iris-s01 bash[567715]: Aug 01 00:02:48 2025 (567715) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=ww10%40lists.example.com&msgid=1f86b244cce9479490b4bffe184f6c03%40sub.example.come HTTP/11" 200 121 Aug 1 00:02:48 iris-s01 bash[567715]: Aug 01 00:02:48 2025 (567715) Starting new HTTPS connection (1): lists.example.com:443 Aug 1 00:02:48 iris-s01 bash[567712]: Aug 01 00:02:48 2025 (567712) Starting new HTTPS connection (1): lists.example.com:443 Aug 1 00:02:48 iris-s01 bash[567712]: Aug 01 00:02:48 2025 (567712) Starting new HTTP connection (1): localhost:8000 Aug 1 00:02:48 iris-s01 bash[567712]: Aug 01 00:02:48 2025 (567712) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=ww10%40lists.example.com&msgid=1f86b244cce9479490b4bffe184f6c03%40sub.example.com HTTP/11" 200 121 Aug 1 00:02:48 iris-s01 bash[567712]: Aug 01 00:02:48 2025 (567712) Starting new HTTPS connection (1): lists.example.com:443 Aug 1 00:02:49 iris-s01 bash[567712]: Aug 01 00:02:49 2025 (567712) Starting new HTTP connection (1): localhost:8000 Aug 1 00:02:49 iris-s01 bash[567712]: Aug 01 00:02:49 2025 (567712) http://localhost:8000 "GET /archives/api/mailman/urls?mlist=ww10%40lists.example.com&msgid=1f86b244cce9479490b4bffe184f6c03%40sub.example.com HTTP/11" 200 121
And then there is a logrotate:
/var/log/mailman/mailman-logs/* { missingok daily compress delaycompress nomail notifempty rotate 14 dateext su mailman mailman olddir /var/log/mailman/mailman-logs/oldlogs create 664 mailman mailman postrotate if [ -f /opt/mailman/var/master.pid ]; then /bin/systemctl restart mailman.service > /dev/null; fi endscript } /var/log/mailman/* { missingok daily compress delaycompress nomail notifempty rotate 14 dateext su mailman mailman olddir /var/log/mailman/oldlogs create 664 mailman mailman }
And yes, this restarts mailman at midnight. Maybe i should optimize the logrotate.
Now to the files:
mailman qfile /opt/mailman/var/queue/virgin/1736550035.6163204+472f81ece5e45a2651a4499bef418f611b43c619.pck.tmp
in object 1 there is a complete mail from 11 January 2025, it's a digest.
In object 2:
<----- start object 2 -----> { '_parsemsg': False, 'isdigest': True, 'listid': '<Name of the List>>', 'recipients': { '<Rec1>', '<Rec2>', '<Rec3>', '<Rec4>'}, 'version': 3}
So i would say there is no error in the mail. But i will delete this file now, because it's older then 6 months.
Now let's move on to the shunt queue: Here is the fole form the 31 July 2025:
mailman qfile /opt/mailman/var/queue/shunt/1753912822.2651796+28eceef7e18eb70393377b88dc7117af8f9362a0.pck
object 1 is empty object 2:
{ '_parsemsg': False, 'digest_number': 1, 'digest_path': '/opt/mailman/var/lists/it-besteller.lists.example.com/digest.11.1.mmdf', 'lang': 'de', 'listid': 'it-besteller.lists.example.com', 'version': 3, 'volume': 11, 'whichq': 'digest'}
Well - this is a digest too. Maybe the restart through the logrotate kills the digest generation?
After looking at all midnights mails: It's the smae: No Mail body and a digest.
Then we have a special mail from 31 July 2025 at 11:44:
mailman qfile /opt/mailman/var/queue/shunt/1753955094.900898+67bc76525412da66a7c76363f65f583989716305.pck <Database line omitted> [----- start pickle -----] <----- start object 1 ----->
<----- start object 2 -----> { '_parsemsg': False, 'digest_number': 6, 'digest_path': '/opt/mailman/var/lists/slcm_fak.lists.example.com/digest.47.6.mmdf', 'lang': 'en', 'listid': 'slcm_fak.lists.example.com', 'version': 3, 'volume': 47, 'whichq': 'digest'} [----- end pickle -----]
Again - an digest. Seems to be a problem with digests. But that does not explain my problem. It's 'just another problem to be fixed' :D
Questions about my setup:
- my local Postfix is connected to a smarthost. In the maillog i can see successfully delivered mails to a lot of people. If there is a problem, i would see it
Maybe there is something problematic with my mailman.cfg?
# For example, uncomment the following lines to run Mailman in developer mode. # # [devmode] # enabled: yes # recipient: your.address@your.domain
[mailman] site_owner: mailman@lists.example.com layout: here pending_request_life: 3d default_language: de
[paths.here] var_dir: /opt/mailman/var log_dir: /var/log/mailman/mailman-logs
[database] class: mailman.database.postgresql.PostgreSQLDatabase url: postgresql://mailman:<Pass>@db01.example.com/mailman debug: no
[runner.out] instances: 4
[archiver.hyperkitty] class: mailman_hyperkitty.Archiver enable: yes configuration: /opt/mailman/mailman-hyperkitty.cfg
[archiver.prototype] enable: yes
[mta] verp_probes: yes verp_confirmations: yes verp_personalized_deliveries: yes verp_delivery_interval: 0 remove_dkim_headers: yes
[webservice] hostname: localhost port: 8001 use_https: no admin_user: mailmanapiuser admin_pass: <PASS> api_version: 3.1 workers: 4 configuration: /opt/mailman/gunicorn.conf
#log_dir: $var_dir/logs [logging.root] level: debug path: mailman.log [logging.archiver] level: debug path: archiver.log [logging.bounce] path: bounce.log level: warn [logging.config] level: debug path: mailman.log [logging.database] level: warn path: database.log [logging.debug] path: debug.log level: warn [logging.error] level: debug path: error.log [logging.fromusenet] level: warn path: mailman.log [logging.http] level: warn path: httpd.log [logging.locks] level: warn path: locks.log [logging.mischief] level: warn path: mailman.log [logging.plugins] path: mailman.log level: warn [logging.runner] level: warn path: runner.log [logging.smtp] path: smtp.log level: debug [logging.subscribe] path: subscribe.log level: debug [logging.vette] path: vette.log level: debug
# Some list posts and mail to the -owner address may contain DomainKey or # DomainKeys Identified Mail (DKIM) signature headers <http://www.dkim.org/>. # Various list transformations to the message such as adding a list header or # footer or scrubbing attachments or even reply-to munging can break these # signatures. It is generally felt that these signatures have value, even if # broken and even if the outgoing message is resigned. However, some sites # may wish to remove these headers by setting this to 'yes'.
[bounces] # How often should the bounce runner process queued detected bounces? register_bounces_every: 15m
[antispam] header_checks: X-Spam-Flag: YES jump_chain: discard
There are no memory peaks on the os side, as far as my monitoring tells me.
So - any other ideas? Hopefully i didn't missed an important detail in your questions.
Stephan Krinetzki writes:
And then there is a logrotate: And yes, this restarts mailman at midnight. Maybe i should optimize the logrotate.
Not sure what you mean by "optimize". Because of the bug I mentioned earlier, in older versions of Mailman 3 the master process would fail to close some of logfiles. After rotation, the master process would continue writing to the still-open file handle, defeating the purpose of logrotate. Unless that bug has been fixed in your version, you should leave the restart stanza in the logrotate for configuring mailman.
That the shunt queue is collecting digests seems weird. It's not surprising that the message object in the queue file is empty, that's by design. It seems like the digest process is happening at the same time as the restart. This shouldn't be a problem, but it might clarify things if you make sure the periodic digest delivery is offset from the midnight restart in the /etc/cron.d/mailman3 file. Eg
# cron time is UTC, put stuff on desks at start of day JST # core sends mail 22 5 * * * mailman /opt/mailman3/.v/bin/mailman notify 22 6 * * * mailman /opt/mailman3/.v/bin/mailman digests --periodic
(note 22:00 UTC is 07:00 JST).
My only other comment on your mail is that I see that you do have multiple out slices. So that explains the case of the .pck.bak (in process) file being younger than a .pck file (waiting in queue). It's not unusual in your configuration.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 8/1/25 01:22, Stephan Krinetzki wrote:
Now to the files:
mailman qfile /opt/mailman/var/queue/virgin/1736550035.6163204+472f81ece5e45a2651a4499bef418f611b43c619.pck.tmp
...
mailman qfile /opt/mailman/var/queue/shunt/1753912822.2651796+28eceef7e18eb70393377b88dc7117af8f9362a0.pck ... mailman qfile /opt/mailman/var/queue/shunt/1753955094.900898+67bc76525412da66a7c76363f65f583989716305.pck
What about
-rw-rw---- 1 mailman mailman 221708 Jul 30 13:16 1753874180.0845337+0cc7849043859a79dc3678a0d8b63c1c66df0c66.pck.tmp and -rw-rw---- 1 mailman mailman 733425 Jul 31 00:00 1753912841.8847518+da55f8789ae41b75d19a02b595e3fd6d45983ade.pck.tmp
from the out queue? And is the out queue being processed, i.e. messages in .pck files being delivered and the files being removed.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On August 2025 1:22 a.m. Stephan Krinetzki wrote:
And then there is a logrotate:
...
postrotate if [ -f /opt/mailman/var/master.pid ]; then /bin/systemctl restart mailman.service > /dev/null; fi
You should be aware that blindly restarting Mailman can result in duplicate messages to list members and possibly other issues. In particular if outgoing runner is processing a message and has already delivered one or more chunks to the MTA, a restart will cause outgoing runner to stop and upon restart, deliver to the entire recipient list resulting in duplicates for those recipients already sent to the MTA.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 7/31/25 00:18, Stephan Krinetzki wrote:
mailman members --regular --nomail enabled LISTSPEC
Shows a lot of addresses - so all the members of the list don't recieve an mail, which explains the vanished mail. Next step: Enable the the mailing for them.
--nomail enabled lists members with delivery enabled, not those with
delivery disabled. See mailman members --help
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Mark Sapiro -
Odhiambo Washington -
Stephan Krinetzki -
Stephen J. Turnbull