[Mailman-Developers] Re: [Mailman-Users] LogMsg problem
Thu, 2 Dec 1999 11:57:21 -0500 (EST)
Sure enough! This was exactly the problem! After applying the 'try:
except:' fix I suggested below I no longer get the error traceback
from LogMsg and I see the following in the bounce log. It was the email
address string containing % characters in LogMsg called from
RegisterBounce that was causing the failure.
Dec 02 11:47:26 1999 cdn-nucl-l: DXS9%OPS%DCPP@bangate.pge.com - exceeded limits
Dec 02 11:47:26 1999 cdn-nucl-l: disabled email@example.com
Dec 02 11:47:27 1999 cdn-nucl-l: firstname.lastname@example.org - first
n Thu, 2 Dec 1999, Todd Pfaff wrote:
> I'm using mailman 1.1. One of our lists consistently generates the
> following python traceback in the mailman error log whenever a message is
> posted to the list.
> Dec 01 13:22:45 1999 post: Traceback (innermost last):
> post: File "/usr/local/mailman/scripts/mailowner", line 45, in ?
> post: if not mlist.bounce_processing or not mlist.ScanMessage(msg):
> post: File "/usr/local/mailman/Mailman/Bouncer.py", line 449, in ScanMessage
> post: self.RegisterBounce(who, msg)
> post: File "/usr/local/mailman/Mailman/Bouncer.py", line 138, in RegisterBounce
> post: self.LogMsg("bounce", report + "exceeded limits")
> post: File "/usr/local/mailman/Mailman/MailList.py", line 834, in LogMsg
> post: logf.write(msg % args + '\n')
> post: TypeError : not enough arguments for format string
> I've had a look at the call to LogMsg() in MailList.py from
> RegisterBounce() in Bouncer.py, so I sort of where the error is happening.
> As far as I can tell, there must be some instances where LogMsg is being
> called with a "msg" argument that contains % variable substitutions that
> have not yet been satisfied, but with an empty or insufficient "args"
> tuple. So, when LogMsg calls logf.write(msg % args + '\n'), the %
> substitution fails.
> It seems that, in general, the use of LogMsg is inconsistent. In some
> cases, a variable length args tuple is passed to LogMsg and the string
> formatting is done within LogMsg, but in many other cases any string
> formatting is done before the call to LogMsg and LogMsg is called without
> an args tuple.
> It's entirely possible that something will call LogMsg with a "msg"
> argument that contains a valid % substitution string even though they did
> not intend for a % substitution to happen. I think this is what may be
> happening in my case - the RegisterBounce() function builds the "msg"
> string from other variable strings and one of these strings may contain a
> % substitution string. This msg string is then passed to LogMsg but
> without an args tuple to satisfy the % substitution.
> I'm no Python expert - I just started learning it a few weeks ago - but
> I'm trying to think of ways to debug this, or handle the situation more
> gracefully. I've been poking through the Python books I have and looking
> at the exception handling stuff. I've come up with the following simple
> idea for handling this in LogMsg(). Any opinions about whether this is a
> good idea, whether it will work, or whether there is a better way to
> approach this problem?
> logf.write(msg % args + '\n')
> logf.write(msg + '\n')
> Todd Pfaff \ Email: email@example.com
> Computing and Information Services \ Voice: (905) 525-9140 x22920
> ABB 132 \ FAX: (905) 528-3773
> McMaster University \
> Hamilton, Ontario, Canada L8S 4M1 \
> Mailman-Users maillist - Mailman-Users@python.org
Todd Pfaff \ Email: firstname.lastname@example.org
Computing and Information Services \ Voice: (905) 525-9140 x22920
ABB 132 \ FAX: (905) 528-3773
McMaster University \
Hamilton, Ontario, Canada L8S 4M1 \