[Mailman-Users] mailman simply *stops* sending messages

[Rob Scott]

Looks like the problem has been cleared up, thanks for pointing me to the digest file again Mark.. the message was somehow both in the qfiles and the digest, maybe sent twice because it apparently dissapeared the first time, anyway.. once I removed the message and its icky dirty accented e in the attachment filename from the digest and restarted mailman began merrily spewing messages again as though nothing had happened.  How cute. For the record I don't think this is really a mailman bug at all.. but thanks for your help in resolving it anyway. 

moral of the story: Python hates the French almost as much as Dubya does.. 


Cheers,


Rob Scott
IMT Consultant

Reboot Consulting Co.
#101-506 John St.
Victoria, BC, V8T 1T6
Main  (250) 380-0377 
Fax   (250) 385-2668

http://www.reboot.ca/





---------------------------------------------------------------------------------------------------------------------
Below is the message being replied to:

>>  Rob Scott wrote:
>>  >
>>  >Thanks a bunch for your help Mark, though I'm afraid I'm not actually
>>  getting any further ahead with this..  I am admittedly a mailman/python
>>  newb but I find it hilarious and somewhat pathetic that python (or is it
>>  actually mailman?) chokes and dies a horrible death on one little
>>  accented e.  I'm just not getting a clear picture of which file(s) I
>>  would need to remove the offending character(s) from, or what the correct
>>  procedure to do so would be.. can I simply grep the digest(s) / qfiles
>>  for that accented e and them strip them out with a text editor?   Any
>>  further insights would be much appreciated!
>>  >
>>  > When running unshunt I now get the following error for each file in
>>  /qfiles/shunt  (22 of them)  
>>  >
>>  >May 20 14:07:31 2005 (4364) SHUNTING:
>>  1116552066.5283909+9c37617d12e1db5cef5b1124ccb0162679814821
>>  >May 20 14:07:31 2005 (4364) Uncaught runner exception: 'ascii' codec
>>  can't decode byte 0xe9 in position 2: ordinal not in range(128)
>>  <rest of trace snipped>

>>  I'm not sure what the issue is that's preventing Mailman from just
>>  continuing processing the lists, so I don't know how much help this
>>  all will be, but ...

>>  lists/<listname>/digest.mbox is a plain text file in Unix mbox format.
>>  You can edit it directly with any text editor that won't wrap or fill
>>  lines, and if you find Content-Type: headers with name= and/or
>>  Content-Disposition: headers with filename= with e-acute or whatever
>>  in the name, you can change it. I think that will fix the senddigests
>>  problem. You can manually run "cron/senddigests -l listname" to
>>  produce the digest.

>>  As far as the shunted messages are concerned, I don't think you can
>>  edit the qfiles/shunt/* files directly, but once a message has been
>>  shunted (placed in the shunt queue), it is no longer processed by
>>  Mailman. Only when bin/unshunt moves it from the shunt queue to its
>>  original queue does Mailman attempt to process it further so this
>>  doesn't explain why list activity has stopped. Is it possible that the
>>  only activity is someone reposting the same bad message?

>>  --
>>  Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
>>  San Francisco Bay Area, California    better use your sense - B. Dylan




---------------------------------------------------------------------------------------------------------------------
This electronic message transmission, including any attached files, contains information which may be confidential and/or privileged. The information is intended to be for the sole use of the individual or entity named above. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution or use of the contents of this information is prohibited. This message is not to be forwarded for any reason without prior consent of the sender. If you have received this electronic transmission in error, please notify the sender immediately by telephone (250) 380-0377 or by a "reply to sender only" message and destroy all electronic and hard copies of the communication, including attachments, without reading or saving in any manner.