[Mailman-Users] How to unshunt?
Ulf Dunkel
dunkel at calamus.net
Mon May 25 18:02:30 CEST 2009
Hi Mark.
> The files in qfiles/retry/ and qfiles/virgin/ are not shunted. If they
> are *.pck files, they should be processed normally by RetryRunner and
> VirginRunner respectively if those runners are running. If they are
> *.bak files, they are 'backup' queue entries that were possibly left
> behind if the runner died while processing a message. If so, they
> should be reprocessed the next time the runner starts.
/qfiles/retry/ contains *.pck files.
/qfiles/virgin/ contains one *.pck.tmp file only.
> Does /var/lib/mailman/bin/unshunt exist and is it executable (mode
> -rwxr-xr-x)?
Yes, it exists there physically (no link or stuff) and is executable
with mode -rwxr-xr-x.
>> What am I doing wrong? When I try
>>
>> $ /var/lib/mailman/bin/python unshunt
>
>
> Do you really have a python in /var/lib/mailman/bin or did you perhaps
> mean
>
> $ python /var/lib/mailman/bin/unshunt
Yepp, of course I meant the latter. Sorry.
> Unshunt will process *.bak and *.pck files in qfiles/shunt/ first
> renaming the .bak files to .pck and then attempting to restore the
> .pck files to their original queue. For any .pck files it can't
> requeue, it should print a "Cannot unshunt message xxxxx, skipping"
> message and leave that file as a .bak in the shunt/ queue.
Sorry, but it doesn't print anything and simply quits. Afterwards, all
existing .pck files in the shunt/ folder have been updated to the
current date+time. That seems to be all. :-o
> You can look at these files with bin/dumpdb -p to see the message and
> the metadata. Each file should contain two objects, the message and
> the metadata. The metadata should have a 'whichq' attribute indicating
> which queue to put it in.
I can see these data for all files, seem to be fine.
> Is it possible that the messages are being unshunted and then throwing
> exceptions in processing and being shunted again?
>
> What do mailman's error and smtp-failure (for retry) logs say?
error says:
---snip---
[...]
May 25 17:57:06 2009 (5320) Uncaught runner exception: 'utf8' codec
can't decode bytes in position 30-35: unsupported Unicode code range
May 25 17:57:06 2009 (5320) Traceback (most recent call last):
File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop
self._onefile(msg, msgdata)
File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File "/usr/lib/mailman/Mailman/Queue/VirginRunner.py", line 38, in
_dispose
return IncomingRunner._dispose(self, mlist, msg, msgdata)
File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in
_dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in
_dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
File "/usr/lib/mailman/Mailman/Handlers/CookHeaders.py", line 188, in
process
i18ndesc = uheader(mlist, mlist.description, 'List-Id', maxlinelen=998)
File "/usr/lib/mailman/Mailman/Handlers/CookHeaders.py", line 65, in
uheader
return Header(s, charset, maxlinelen, header_name, continuation_ws)
File "/usr/lib/mailman/pythonlib/email/Header.py", line 188, in __init__
self.append(s, charset, errors)
File "/usr/lib/mailman/pythonlib/email/Header.py", line 272, in append
ustr = unicode(s, incodec, errors)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 30-35:
unsupported Unicode code range
May 25 17:57:06 2009 (5320) SHUNTING:
1243264080.014122+b4e9af652fe7695880609b2edfb94ed8841bbfb3
---snap---
smtp-failure says:
----- snip -----
[...]
May 25 17:56:38 2009 (5319) All recipients refused:
{'udo_discussion-owner at lists.udo-open-source.org': (451, 'Temporary
local problem - please try later')}, msg
May 25 17:56:38 2009 (5319) delivery to
udo_discussion-owner at lists.udo-open-source.org failed with code 451:
Temporary local problem - please try later
----- snap -----
What the heck should I do? I have no idea where else I should search for
"wrong" utf8 stuff and what "Temporary local problem" means.
As always, Mark: I really appreciate your help. :-)
--UlfDunkel
More information about the Mailman-Users
mailing list