4.35. What do I do with a shunt (qfiles/shunt) directory full of files?

I was using 2.1.2 (Red Hat's 2.1.2-2), and got the problem where the digester would bomb out with "ValueError: Empty module name". By the time I got around to dealing with it, my shunt directory had about 226 megabytes of stuff in it. I upgraded to 2.1.4 (Red Hat's 2.1.4-2 from rawhide) and that problem seems to be solved, but now I get:

/var/mailman/pythonlib/japanese/c/iso_2022_jp.py:4: RuntimeWarning: Python C API version mismatch for module
_japanese_codecs: This Python has API version 1011, module _japanese_codecs has version 1012.
import codecs, japanese.c._japanese_codecs

(on a Red Hat 9 system with all patches) and meanwhile, the stuff is still all stuck in the shunt directory.

I'm not having much luck finding docs that even explain the shunt directory.

So:

1. What is the shunt directory exactly?
2. (more importantly) How can I persuade Mailman to deliver the stuff that's in the shunt directory?
3. Is there any chance that messages in the shunt directory have made it far enought through mailman to be delivered? I recently ran "unshunt" and got complaints of duplicates from many folks. It was my understanding that anything in the shunt queue has not been delivered. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. The shunt directory is a place where messages go when there is an error with some functions that process them. In my case, it was because of an archiving error in version 2.1.3 that was fixed with an upgrade to 2.1.4

2. To fix it, there is a program called unshunt in the ~/mailman/bin directory. You simply run it from the command line; you don't need any special parameters:

% path-to-mailman/bin/unshunt

3. Mark Sapiro gave an excellent answer to this on the -users list. Here it is in brief:

"If a message is shunted because SMTPDirect.py can't write the 'post' log, it has already been sent, but OutgoingRunner.py doesn't know this when it catches the exception and shunts the message. So those messages which were shunted because of ownership/permission issues on the 'post' log probably were duplicated when you ran unshunt."

I also imagine the same logic applies for various other errors. In short, a message CAN both be delivered and end up in the shunt queue, so you need to carefully look at everything in the shunt queue before unshunting.

Converted from the Mailman FAQ Wizard

This is one of many Frequently Asked Questions.