[Mailman-Users] Mailman continues to deliver to deleted list
mark at msapiro.net
Wed Nov 7 15:56:01 CET 2012
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
- 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 at msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
More information about the Mailman-Users