FAQ
One mailman instance that I work with is running 2.1.2 on a linux
2.4.20-20.9 kernel.

Mail to a specific list is not getting delivered, but other lists on the
same instance are being delivered fine. The error message one person got
back when they tried to send a message to the list was:

==== start error message ===
Traceback (most recent call last):
File "/usr/local/mailman/cron/senddigests", line 94, in ?
main()
File "/usr/local/mailman/cron/senddigests", line 86, in main
mlist.send_digest_now()
File "/usr/local/mailman/Mailman/Digester.py", line 60, in send_digest_now
ToDigest.send_digests(self, mboxfp)
File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 130, in send_digests
send_i18n_digests(mlist, mboxfp)
File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 303, in send_i18n_digests
msg = scrubber(mlist, msg)
File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 232, in process
url = save_attachment(mlist, part, dir)
File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 348, in save_attachment
fnext = os.path.splitext(msg.get_filename(''))[1]
File "/usr/local/mailman/pythonlib/email/Message.py", line 707, in get_filename
return unicode(newvalue[2], newvalue[0])
TypeError: unicode() argument 2 must be string, not None
==== end error message ===


I read this message to the list that is dated January 2006:
==
Mailman sends messages in both regular and digest delivery. The digest
processing is inserted in the middle of regular delivery if the messages
accumulated to a preset amount. If there is a serious error in the
digest processing, the regular delivery fails. Since the messages are
accumulated already, arrival of following message triggers the digest
processing again and also fail in the subsequent regular delivery.
==

It went on to say:
==
Therefore, the site administrator should check the qfiles/shunt
directory and the logs/error file periodically.
==

The recommendation was to go to 2.1.7 of mailman. Well, I'd rather not do
that with all the lists going right now. I'll need to do that later.

I guess something bombed with the digestifying. We don't digest the
specific list, so I tried turning that off on the list, but that didn't
help any. I saw in the FAQ to try "unshunt", but that doesn't seemed to
have unstick the log jam. There are quite a few files in the qfiles/shunt
directory.

Is there a command or a set of procedures that I can run to make the list
start delivering mail again normally?

Hal Huntley
SRI International

Search Discussions

  • Mark Sapiro at Apr 11, 2006 at 1:45 am

    Hal Huntley wrote:
    One mailman instance that I work with is running 2.1.2 on a linux
    2.4.20-20.9 kernel.

    Mail to a specific list is not getting delivered, but other lists on the
    same instance are being delivered fine.

    <snip>
    Is there a command or a set of procedures that I can run to make the list
    start delivering mail again normally?
    It definitely appears to be a digesting issue.

    Rename or move aside the file lists/<listname>/digest.mbox. That should
    get the list going again.

    It looks like there may be a message there with an attachment with a
    null filename.

    I think all the known problems of this type with scrubber are fixed in
    2.1.8.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedApr 11, '06 at 1:07a
activeApr 11, '06 at 1:45a
posts2
users2
websitelist.org

2 users in discussion

Hal Huntley: 1 post Mark Sapiro: 1 post

People

Translate

site design / logo © 2022 Grokbase