[Mailman-Users] Confirmation problems

[Mark Sapiro]

Niemi Hannu wrote:
>
>After evaluating the problem again it seems that my first impression was a
>bit erroneous (read I didn't debug efficiently enough):
>
>It seems that confirming via web page works, but only if one hasn't tried to do it by mail. It seems that the mail removes the confirmation from the pending confirmations, but doesn't do the trick.


What are the subscription rules? is moderator approval also required?
Is this why the confirmation by email appears to not work?


>And after that the web page confirmation doesn't really have anything to confirm against.
>
>The error log gives the following information:
>
>-----------------8<--------------8<-----------------
>
>Feb 08 21:26:11 2006 (29601) Uncaught runner exception: [Errno 9] Bad file =
>descriptor
>Feb 08 21:26:11 2006 (29601) Traceback (most recent call last):
>  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop
>    self._onefile(msg, msgdata)
>  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile
>    keepqueued =3D self._dispose(mlist, msg, msgdata)
>  File "/usr/lib/mailman/Mailman/Queue/OutgoingRunner.py", line 74, in _dis=
>pose
>    self._func(mlist, msg, msgdata)
>  File "/usr/lib/mailman/Mailman/Handlers/SMTPDirect.py", line 180, in proc=
>ess
>    mm_cfg.SMTP_LOG_EVERY_MESSAGE[1], kws=3Dd)
>  File "/usr/lib/mailman/Mailman/Logging/Syslog.py", line 49, in write_ex
>    logf =3D self._logfiles[kind] =3D StampedLogger(kind)
>  File "/usr/lib/mailman/Mailman/Logging/StampedLogger.py", line 52, in __i=
>nit__
>    Logger.__init__(self, category, nofail, immediate)
>  File "/usr/lib/mailman/Mailman/Logging/Logger.py", line 49, in __init__
>    self.__get_f()
>  File "/usr/lib/mailman/Mailman/Logging/Logger.py", line 75, in __get_f
>    _logexc(self, e)
>  File "/usr/lib/mailman/Mailman/Logging/Utils.py", line 22, in _logexc
>    sys.__stderr__.write('Logging error: %s\n' % logger)
>IOError: [Errno 9] Bad file descriptor
>
>Feb 08 21:26:11 2006 (29601) SHUNTING: 1139426770.15838+256c6fef5c6868ee41812a6ec8d71a9d1da73730

Do (watch out for folding)

bin/show_qfiles
qfiles/shunt/1139426770.15838+256c6fef5c6868ee41812a6ec8d71a9d1da73730.pck

And see what's in the shunted message. Unless you have a large number
of these, I don't know what happened to cause this.

What the trace shows is the SMTP delivery handler successfully
delivered the message to the outgoing MTA and was trying to log that
fact in the 'smtp' log, but for some reason logging encountered an
exception (I think) and tried to write that to stderr which wasn't
available, so the error logged here is the inability to write to
stderr.

Also, the actual message in this case that was shunted, should have
been successfully delivered anyway, so this seems to have nothing to
do with the confirmation problem.

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