Mailman continues to deliver to deleted list

Folks,
I deleted a mailing list using rmlist. However, mailman continues to send out messages to the recipients on this list, and I can't seem to make it stop. There's ~~ 3000 pending deliveries, so I'd really rather that they not go out.
For now mailman is shut down. How do I clean out its pending messages queue entirely?
-- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

Josh Berkus wrote:
Folks,
I deleted a mailing list using rmlist. However, mailman continues to send out messages to the recipients on this list, and I can't seem to make it stop. There's ~~ 3000 pending deliveries, so I'd really rather that they not go out.
For now mailman is shut down. How do I clean out its pending messages queue entirely?
First of all, if the list is gone, i.e. there is no lists/LISTNAME/ directory in Mailman's hierarchy, no currently queued messages will be processed. Outgoing runner or some other runner may pick up queue entries for this list, but the list won't be there, so the queued message will be shunted with an error log message 'Dequeuing message destined for missing list: LISTNAME'. Therefore, you can just restart Mailman and any messages in Mailman's queues from the affected list will just wind up in the shunt queue and won't be processed.
Thus, any 'pending' deliveries which will go out have already been delivered from Mailman to the MTA, and stopping them has to be done in the MTA (unless that's moot at this point).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 11/5/2012 8:02 PM, Mark Sapiro wrote:
Josh Berkus wrote:
Folks,
I deleted a mailing list using rmlist. However, mailman continues to send out messages to the recipients on this list, and I can't seem to make it stop. There's ~~ 3000 pending deliveries, so I'd really rather that they not go out.
For now mailman is shut down. How do I clean out its pending messages queue entirely?
First of all, if the list is gone, i.e. there is no lists/LISTNAME/ directory in Mailman's hierarchy, no currently queued messages will be processed. Outgoing runner or some other runner may pick up queue entries for this list, but the list won't be there, so the queued message will be shunted with an error log message 'Dequeuing message destined for missing list: LISTNAME'. Therefore, you can just restart Mailman and any messages in Mailman's queues from the affected list will just wind up in the shunt queue and won't be processed.
Thus, any 'pending' deliveries which will go out have already been delivered from Mailman to the MTA, and stopping them has to be done in the MTA (unless that's moot at this point).
I have a shell script that I use to remove email from the postfix queue based on some unique text string. This is only for postfix and is kinda crude, but it works ;)
It should run on any *nix system.

- Mark Sapiro <mark@msapiro.net>:
First of all, if the list is gone, i.e. there is no lists/LISTNAME/ directory in Mailman's hierarchy, no currently queued messages will be processed. Outgoing runner or some other runner may pick up queue entries for this list, but the list won't be there, so the queued message will be shunted with an error log message 'Dequeuing message destined for missing list: LISTNAME'. Therefore, you can just restart Mailman and any messages in Mailman's queues from the affected list will just wind up in the shunt queue and won't be processed.
I am aware of how to get rid of shunted messages but I'd like to know if there are performance penalites for keeping a moderate amount (<1k) of messages around in the shunted queue for about a month.
As far as I understand, the shunted queue is not directly involved in message delivery, so there should be no performance hit, right? This way I could "play it safe", keep those messages around for a certain time (they might turn out important after all) and then have a cron job delete them.
Thanks Stefan

On 11/6/2012 9:38 PM, Stefan Foerster wrote:
I am aware of how to get rid of shunted messages but I'd like to know if there are performance penalites for keeping a moderate amount (<1k) of messages around in the shunted queue for about a month.
As far as I understand, the shunted queue is not directly involved in message delivery, so there should be no performance hit, right? This way I could "play it safe", keep those messages around for a certain time (they might turn out important after all) and then have a cron job delete them.
You are correct that the shunt queue is not involved in normal delivery. The only hit would be when shunting an additional message. If the physical size of the qfiles/shunt/ directory in the file system is large, there is additional overhead each time another message is shunted because the entire physical directory must be searched, even if it is empty, to ensure the new entry is not a duplicate name.
Regarding a cron job, the following is from Mailman's NEWS file
2.1.11 (30-Jun-2008)
New Features
- Added a new cron/cull_bad_shunt script to cull and optionally
archive old entries from the bad and shunt queues. This is controlled
by new Defaults.py/mm_cfg.py settings BAD_SHUNT_STALE_AFTER (default
7 days) and BAD_SHUNT_ARCHIVE_DIRECTORY (default None) which determine
how long to keep bad and shunt queue entries and optionally, where to
archive removed entries.
Note that this means that in a default configuration since 2.1.11, shunt queue entries are deleted after 7 days. Do disable this, set
BAD_SHUNT_STALE_AFTER = 0
in mm_cfg.py. To keep them for a month, set
BAD_SHUNT_STALE_AFTER = days(30)
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

All,
FWIW, the queue emptied out after a few hours of my original report.
Since I both deleted the list and emptied the postfix queue, I'm still mystified as to why it didn't empty out immediately though.
-- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com

On 11/7/2012 10:06 AM, Josh Berkus wrote:
Since I both deleted the list and emptied the postfix queue, I'm still mystified as to why it didn't empty out immediately though.
If you delete a list and Mailman's OutgoingRunner is processing a message for that list, as long as the runner is still running, it will continue to process that one message until all recipients have been delivered to the MTA. The only way to stop that is to SIGKILL the runner.
If you are referring to additional message entries in qfiles/out/, those will be processed in sequence by OutgoingRunner, but nothing will be delivered from them because the runner will determine that the list is gone and just log the fact and move the queue entry to qfiles/shunt/.
If neither of the above explains your observation, then I don't know (at least without more information) what was going on.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Josh Berkus
-
Mark Sapiro
-
Richard Shetron
-
Stefan Foerster