Re: [Mailman-Users] Strange errors

2005-10-21 Thread Dan Szkola
Mark Sapiro wrote:

Dan Szkola wrote:
  

The python 2.4.1 was compiled from source and is the only python version 
on the box.



In a later post, you say it wasn't, but you removed the Sun Gnome
Python 2.3. I hope that fixes it, but I doubt it will.
  

It did not. It was doubtful mailman could find that python, due to it 
being in
/usr/sfw, but one never knows for sure.

Here's something else to try if it fails again. As the mailman user in
the /usr/local/mailman directory, give the command

python2.4 -S /usr/local/mailman/scripts/admin listname file

Except for the fact that this doesn't edit the environment passed to
the script, it is the same as invoking the script from the wrapper. If
it works, it will produce an 'unrecognized bounce' which will be
forwarded to the list owner if the option to do so is selected. If it
doesn't work, it will produce a similar output to the above, but the
key is that if it doesn't work, we'll know that the problem, even
though fixed by restarting sendmail and not by restarting Mailman,
occurs even though sendmail doesn't directly invoke the script via the
wrapper. If it does work, we'll know that it involves the script being
invoked through the wrapper.

  

It did work, 5 straight times I got the normal Uncaught bounce 
notification message.

You could then try

/usr/local/mailman/mail/mailman admin listname file

to see if it occurs when you rather than sendmail invoke the wrapper,
but this has to be done from the group that sendmail uses, i.e., the
group that the wrapper expects to be invoked by. Otherwise, the
wrapper will complain because this is exactly the security violation
the wrapper is supposed to catch.

  

Same here, works every time, sending the Uncaught bounce notification 
message.

Only seems to happen when run by the sendmail process.

--
Dan Szkola
Sr Unix Systems Programmer
Northern Illinois University

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-21 Thread Dan Szkola
OK, I found something extremely odd. For some reason,
the Utils.pyc in /usr/local/mailman/Mailman/Logging
direcotry is being removed and then the compile of it
seems to fail and I'm left with a 0 byte file. It is
owned by the daemon user and later it gets compiled
and is owned by the mailman user.

# ls -l
total 60
-rw-r--r--   1 root mailman 3380 May 31 08:39 Logger.py
-rw-r--r--   1 www  mailman 3175 May 31 08:43 Logger.pyc
-rw-r--r--   1 root mailman 2559 May 31 08:39 MultiLogger.py
-rw-r--r--   1 root mailman 2133 May 31 08:43 MultiLogger.pyc
-rw-r--r--   1 root mailman 3204 May 31 08:39 StampedLogger.py
-rw-r--r--   1 www  mailman 2933 May 31 08:43 StampedLogger.pyc
-rw-r--r--   1 root mailman 2221 May 31 08:39 Syslog.py
-rw-r--r--   1 www  mailman 1709 May 31 08:43 Syslog.pyc
-rw-r--r--   1 root mailman 1912 May 31 08:39 Utils.py
-rw-r--r--   1 daemon   mailman0 Oct 21 09:27 Utils.pyc
-rw-r--r--   1 root mailman  785 May 31 08:39 __init__.py
-rw-r--r--   1 www  mailman  126 May 31 08:43 __init__.pyc

# ls -l
total 64
-rw-r--r--   1 root mailman 3380 May 31 08:39 Logger.py
-rw-r--r--   1 www  mailman 3175 May 31 08:43 Logger.pyc
-rw-r--r--   1 root mailman 2559 May 31 08:39 MultiLogger.py
-rw-r--r--   1 root mailman 2133 May 31 08:43 MultiLogger.pyc
-rw-r--r--   1 root mailman 3204 May 31 08:39 StampedLogger.py
-rw-r--r--   1 www  mailman 2933 May 31 08:43 StampedLogger.pyc
-rw-r--r--   1 root mailman 2221 May 31 08:39 Syslog.py
-rw-r--r--   1 www  mailman 1709 May 31 08:43 Syslog.pyc
-rw-r--r--   1 root mailman 1912 May 31 08:39 Utils.py
-rw-r--r--   1 mailman  mailman 1308 Oct 21 09:30 Utils.pyc
-rw-r--r--   1 root mailman  785 May 31 08:39 __init__.py
-rw-r--r--   1 www  mailman  126 May 31 08:43 __init__.pyc

--
Dan Szkola
Sr Unix Systems Programmer
NOrthern Illinois University
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-21 Thread Mark Sapiro
Dan Szkola wrote:

OK, I found something extremely odd. For some reason,
the Utils.pyc in /usr/local/mailman/Mailman/Logging
direcotry is being removed and then the compile of it
seems to fail and I'm left with a 0 byte file. It is
owned by the daemon user and later it gets compiled
and is owned by the mailman user.

# ls -l
total 60
-rw-r--r--   1 root mailman 3380 May 31 08:39 Logger.py
-rw-r--r--   1 www  mailman 3175 May 31 08:43 Logger.pyc
-rw-r--r--   1 root mailman 2559 May 31 08:39 MultiLogger.py
-rw-r--r--   1 root mailman 2133 May 31 08:43 MultiLogger.pyc
-rw-r--r--   1 root mailman 3204 May 31 08:39 StampedLogger.py
-rw-r--r--   1 www  mailman 2933 May 31 08:43 StampedLogger.pyc
-rw-r--r--   1 root mailman 2221 May 31 08:39 Syslog.py
-rw-r--r--   1 www  mailman 1709 May 31 08:43 Syslog.pyc
-rw-r--r--   1 root mailman 1912 May 31 08:39 Utils.py
-rw-r--r--   1 daemon   mailman0 Oct 21 09:27 Utils.pyc
-rw-r--r--   1 root mailman  785 May 31 08:39 __init__.py
-rw-r--r--   1 www  mailman  126 May 31 08:43 __init__.pyc

# ls -l
total 64
-rw-r--r--   1 root mailman 3380 May 31 08:39 Logger.py
-rw-r--r--   1 www  mailman 3175 May 31 08:43 Logger.pyc
-rw-r--r--   1 root mailman 2559 May 31 08:39 MultiLogger.py
-rw-r--r--   1 root mailman 2133 May 31 08:43 MultiLogger.pyc
-rw-r--r--   1 root mailman 3204 May 31 08:39 StampedLogger.py
-rw-r--r--   1 www  mailman 2933 May 31 08:43 StampedLogger.pyc
-rw-r--r--   1 root mailman 2221 May 31 08:39 Syslog.py
-rw-r--r--   1 www  mailman 1709 May 31 08:43 Syslog.pyc
-rw-r--r--   1 root mailman 1912 May 31 08:39 Utils.py
-rw-r--r--   1 mailman  mailman 1308 Oct 21 09:30 Utils.pyc
-rw-r--r--   1 root mailman  785 May 31 08:39 __init__.py
-rw-r--r--   1 www  mailman  126 May 31 08:43 __init__.pyc

Presumably daemon is the user that sendmail uses to invoke the wrapper.
When you tried invoking the wrapper manually and did not get the
error, were you running it as the daemon user? If not, you might try
that.

The recompiling is strange in itself. Normally, if the .pyc is more
recent than the .py, accessible and not corrupt, it is just used, so
once you have a good one, why is python trying to recompile it? And if
Python is recompiling this module when invoked in the 'odd' way, is it
also doing others, and why does this cause a problem (if it is a
cause)?

Do any other Mailman .pyc files have way more recent dates than the
corresponding .py, or are any others owned by 'daemon'?

Maybe next time try something like

find /usr/local/mailman -type f -a \( -mtime 0 -o -user daemon \)

Also, try running the

/usr/local/mailman/mail/mailman admin listname file

as user daemon and the appropriate group if you haven't already.

I really don't understand what's happening since sendmail should always
be invoking the wrapper with the same user:group and that works at
first.

In order to even more closely mimic sendmail, you could try

cat file | /usr/local/mailman/mail/mailman admin listname

instead of the above. Beyond that, the only difference I can see is the
environment, but we say previously, after the wrapper got done with
the environment, all that was there was

PYTHONPATH /usr/local/mailman
AGENT sendmail

and PYTHONPATH is always put there by the wrapper and presumably AGENT
is always put there by sendmail.

So, why does it only seem to fail when sendmail invokes it and only
after some successful invocations, and why does restarting sendmail
fix it while restarting Mailman (which will recompile
/usr/local/mailman/Mailman/Logging/Utils.py) doesn't fix it?

Maybe we need to take this to comp.lang.python.

-- 
Mark Sapiro [EMAIL PROTECTED]   The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-21 Thread Dan Szkola
Mark Sapiro wrote:
 Dan Szkola wrote:
 
 
OK, I found something extremely odd. For some reason,
the Utils.pyc in /usr/local/mailman/Mailman/Logging
direcotry is being removed and then the compile of it
seems to fail and I'm left with a 0 byte file. It is
owned by the daemon user and later it gets compiled
and is owned by the mailman user.

 Presumably daemon is the user that sendmail uses to invoke the wrapper.
 When you tried invoking the wrapper manually and did not get the
 error, were you running it as the daemon user? If not, you might try
 that.

Did that, same thing:

$ id
uid=1(daemon) gid=1(other)
$ /usr/local/mailman/mail/mailman admin esstest /var/tmp/testmessage
HZ
TERM vt100
SHELL /usr/bin/sh
TZ US/Central
PYTHONPATH /usr/local/mailman
LOGNAME daemon
MAIL /var/mail/daemon
HOME /
before = /usr/local/mailman/scripts
before = /usr/local/mailman
before = /usr/local/lib/python24.zip
before = /usr/local/lib/python2.4/
before = /usr/local/lib/python2.4/plat-sunos5
before = /usr/local/lib/python2.4/lib-tk
before = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/mailman/pythonlib
after = /usr/local/mailman
after = /usr/local/mailman/scripts
after = /usr/local/mailman
after = /usr/local/lib/python24.zip
after = /usr/local/lib/python2.4/
after = /usr/local/lib/python2.4/plat-sunos5
after = /usr/local/lib/python2.4/lib-tk
after = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/lib/python2.4/site-packages



 The recompiling is strange in itself. Normally, if the .pyc is more
 recent than the .py, accessible and not corrupt, it is just used, so
 once you have a good one, why is python trying to recompile it? And if
 Python is recompiling this module when invoked in the 'odd' way, is it
 also doing others, and why does this cause a problem (if it is a
 cause)?

Very odd, I agree. A truss of the persistent queue runner that handled
one of the test mails shows this (12762 is the pid that mailman gets
when sendmail exec's it):

  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utilsmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.py, 
O_RDONLY) = 66
  12762:  fstat64(66, 0xFFBF8928) = 0
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.pyc, 
O_RDONLY) = 256
  12762:  close(256)  = 0
  12762:  fstat64(66, 0xFFBF83C8) = 0
  12762:  fstat64(66, 0xFFBF8270) = 0
  12762:  ioctl(66, TCGETA, 0xFFBF8354)   Err#25 ENOTTY
  12762:  read(66,  #   C o p y r i g h t  .., 8192)= 1912
  12762:  read(66, 0x001F902C, 8192)  = 0
  12762:  unlink(/usr/local/mailman/Mailman/Logging/Utils.pyc) = 0
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.pyc, 
O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0666) = 256
  12762:  fcntl(256, F_GETFD, 0xFEFE7F18) = 0
  12762:  stat64(/usr/local/mailman/Mailman/Logging/traceback, 
0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/traceback.so, 
O_RDONLY) Err#2 ENOENT
  12762: 
open64(/usr/local/mailman/Mailman/Logging/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/traceback.py, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/traceback.pyc, 
O_RDONLY) Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/pythonlib/traceback, 0xFFBF7AD0) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/traceback.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/traceback.py, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/traceback.pyc, O_RDONLY) 
Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/traceback, 0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.so, O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/tracebackmodule.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.py, O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.pyc, O_RDONLY) Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/scripts/traceback, 0xFFBF7AD0) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/traceback.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/traceback.py, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/traceback.pyc, O_RDONLY) 
Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/traceback, 0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.so, O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/tracebackmodule.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.py, O_RDONLY) Err#2 ENOENT
  12762:  

Re: [Mailman-Users] Strange errors

2005-10-21 Thread Mark Sapiro
Dan Szkola wrote:

Very odd, I agree. A truss of the persistent queue runner that handled
one of the test mails shows this (12762 is the pid that mailman gets
when sendmail exec's it):

  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utilsmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.py, 
O_RDONLY) = 66
  12762:  fstat64(66, 0xFFBF8928) = 0
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.pyc, 
O_RDONLY) = 256
  12762:  close(256)  = 0
  12762:  fstat64(66, 0xFFBF83C8) = 0
  12762:  fstat64(66, 0xFFBF8270) = 0
  12762:  ioctl(66, TCGETA, 0xFFBF8354)   Err#25 ENOTTY
  12762:  read(66,  #   C o p y r i g h t  .., 8192)= 1912
  12762:  read(66, 0x001F902C, 8192)  = 0
  12762:  unlink(/usr/local/mailman/Mailman/Logging/Utils.pyc) = 0
  12762:  open64(/usr/local/mailman/Mailman/Logging/Utils.pyc, 
O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0666) = 256
  12762:  fcntl(256, F_GETFD, 0xFEFE7F18) = 0
  12762:  stat64(/usr/local/mailman/Mailman/Logging/traceback, 
0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/traceback.so, 
O_RDONLY) Err#2 ENOENT
  12762: 
open64(/usr/local/mailman/Mailman/Logging/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/traceback.py, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/Mailman/Logging/traceback.pyc, 
O_RDONLY) Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/pythonlib/traceback, 0xFFBF7AD0) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/traceback.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/traceback.py, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/pythonlib/traceback.pyc, O_RDONLY) 
Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/traceback, 0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.so, O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/tracebackmodule.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.py, O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.pyc, O_RDONLY) Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/scripts/traceback, 0xFFBF7AD0) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/traceback.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/traceback.py, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/scripts/traceback.pyc, O_RDONLY) 
Err#2 ENOENT
  12762:  stat64(/usr/local/mailman/traceback, 0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.so, O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/tracebackmodule.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.py, O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/mailman/traceback.pyc, O_RDONLY) Err#2 ENOENT
  12762:  stat64(/usr/local/lib/python24.zip/traceback, 0xFFBF7AD0) 
Err#2 ENOENT
  12762:  open64(/usr/local/lib/python24.zip/traceback.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/lib/python24.zip/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python24.zip/traceback.py, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/lib/python24.zip/traceback.pyc, O_RDONLY) 
Err#2 ENOENT
  12762:  stat64(/usr/local/lib/python2.4/traceback, 0xFFBF7AD0) Err#2 
ENOENT
  12762:  open64(/usr/local/lib/python2.4/traceback.so, O_RDONLY) 
Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/traceback.py, O_RDONLY) = 257
  12762:  close(257)  = 0
  12762:  open64(/usr/local/lib/python2.4/traceback.pyc, O_RDONLY) = 257
  12762:  close(257)  = 0
  12762:  stat64(/usr/local/lib/python2.4/plat-sunos5/traceback, 
0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/plat-sunos5/traceback.so, 
O_RDONLY) Err#2 ENOENT
  12762: 
open64(/usr/local/lib/python2.4/plat-sunos5/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/plat-sunos5/traceback.py, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/plat-sunos5/traceback.pyc, 
O_RDONLY) Err#2 ENOENT
  12762:  stat64(/usr/local/lib/python2.4/lib-tk/traceback, 
0xFFBF7AD0) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/lib-tk/traceback.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/lib-tk/tracebackmodule.so, 
O_RDONLY) Err#2 ENOENT
  12762:  open64(/usr/local/lib/python2.4/lib-tk/traceback.py, 
O_RDONLY) Err#2 

Re: [Mailman-Users] Strange errors

2005-10-21 Thread Daniel Szkola
Mark Sapiro wrote:
 Dan Szkola wrote:
You can see it actually unlink the compiled version and then look
for, find, and seemingly reject the traceback.py and traceback.pyc
that it finds. I thought it may be a too many open files problem
or a file descriptor limit problem because the FD returned on the
open64(/usr/local/mailman/Mailman/Logging/Utils.pyc, O_RDONLY)
was 256. But it doesn't return an error. I did see that the ulimit
does say 256 open files is the max, but that doesn't seem to be
the problem.
 
 
 Are you sure this isn't the problem? This is the first thing I've seen
 in this entire thread that begins to make sense, and it appears to me
 as if it can explain the whole thing.

This was my initial thought as well.

 I know truss is not showing an error, but it is too much of a
 coincidence that the open of
 /usr/local/mailman/Mailman/Logging/Utils.pyc returns fd=256
 (presumably the 257th file) and then Python wants to create a new one
 and then the opens of /usr/local/lib/python2.4/traceback.py and
 /usr/local/lib/python2.4/traceback.pyc return fd=257 and Python
 doesn't see them.

It does not explain why it takes some amount of time to be exposed.
Is sendmail leaking file descriptors? How is it that it always runs
out of file descriptors at that exact point?

I thought too many open files should throw an Err#24 EMFILE, but
I'm seeing evidence from googling that shows what we are seeing.

 Is it possible that at the level of truss, there is no error and the
 limit of 256 files (fd = 255 ?) is enforced higher up where the
 resulting error doesn't get traced?

Maybe so. I read where someone said that the close immediately
following the open means the FD was rejected.

Still raises questions, but at least I feel like we got somewhere
in debugging this issue.

--
Dan Szkola
Sr Unix Systems Programmer
Northern Illinois University


--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-19 Thread Dan Szkola
Mark Sapiro wrote:

Dan Szkola wrote (in separate posts):
  

You could try the following patch to the $prefix/scripts/post script to
print the environment each time it is invoked. Assuming sendmail
doesn't choke on this in the normal case, it should appear in the DSN
in the error case.
  

Patched the admin script as suggested. When I saw the error this 
morning, I emailed
to the admin address of our test list. Here is what I got:

   - Transcript of session follows -
PYTHONPATH /usr/local/mailman
AGENT sendmail
Traceback (most recent call last):
  File /usr/local/mailman/scripts/admin, line 36, in ?
from Mailman.Queue.sbcache import get_switchboard
  File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
from Mailman.Queue.Switchboard import Switchboard
  File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in ?
from Mailman.Logging.Syslog import syslog
  File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
from Mailman.Logging.StampedLogger import StampedLogger
  File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20, in ?
from Mailman.Logging.Logger import Logger
  File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
from Mailman.Logging.Utils import _logexc
  File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

--
Dan Szkola
Sr Unix Systems Programmer
Northern Illinois University

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-19 Thread Dan Szkola
Mark Sapiro wrote:

Dan Szkola wrote:

  

Patched the admin script as suggested. When I saw the error this 
morning, I emailed
to the admin address of our test list. Here is what I got:

  - Transcript of session follows -
PYTHONPATH /usr/local/mailman



I wouldn't have expected this, but I don't think it should matter.

What do you get if you add to the patch as follows

--- admin   2005-10-14 16:31:42.078125000 -0700
+++ admin_patched   2005-10-19 10:21:51.328125000 -0700
@@ -25,8 +25,16 @@
 

 import sys
+from os import environ
+for env_var in environ:
+print env_var, environ[env_var]
+for s_path in sys.path:
+print 'before =', s_path

 import paths
+for s_path in sys.path:
+print 'after =', s_path
+
 from Mailman import mm_cfg
 from Mailman import Utils
 from Mailman.i18n import _


  

   - Transcript of session follows -
PYTHONPATH /usr/local/mailman
AGENT sendmail
before = /usr/local/mailman/scripts
before = /usr/local/mailman
before = /usr/local/lib/python24.zip
before = /usr/local/lib/python2.4/
before = /usr/local/lib/python2.4/plat-sunos5
before = /usr/local/lib/python2.4/lib-tk
before = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/mailman/pythonlib
after = /usr/local/mailman
after = /usr/local/mailman/scripts
after = /usr/local/mailman
after = /usr/local/lib/python24.zip
after = /usr/local/lib/python2.4/
after = /usr/local/lib/python2.4/plat-sunos5
after = /usr/local/lib/python2.4/lib-tk
after = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/lib/python2.4/site-packages
Traceback (most recent call last):
  File /usr/local/mailman/scripts/admin, line 42, in ?
from Mailman.Queue.sbcache import get_switchboard
  File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
from Mailman.Queue.Switchboard import Switchboard
  File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in ?
from Mailman.Logging.Syslog import syslog
  File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
from Mailman.Logging.StampedLogger import StampedLogger
  File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20, in ?
from Mailman.Logging.Logger import Logger
  File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
from Mailman.Logging.Utils import _logexc
  File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

Oddly, the correct path statement is the only one with a trailing slash.

--
Dan Szkola
Sr Unix Systems Programmer
Northern Illinois University

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-19 Thread John W. Baxter
On 10/19/05 11:14 AM, Dan Szkola [EMAIL PROTECTED] wrote:

 Mark Sapiro wrote:
 
 Dan Szkola wrote:
 
  
 
 Patched the admin script as suggested. When I saw the error this
 morning, I emailed
 to the admin address of our test list. Here is what I got:
 
  - Transcript of session follows -
 PYTHONPATH /usr/local/mailman

 
 
 I wouldn't have expected this, but I don't think it should matter.
 
 What do you get if you add to the patch as follows
 
 --- admin   2005-10-14 16:31:42.078125000 -0700
 +++ admin_patched   2005-10-19 10:21:51.328125000 -0700
 @@ -25,8 +25,16 @@
 
 
 import sys
 +from os import environ
 +for env_var in environ:
 +print env_var, environ[env_var]
 +for s_path in sys.path:
 +print 'before =', s_path
 
 import paths
 +for s_path in sys.path:
 +print 'after =', s_path
 +
 from Mailman import mm_cfg
 from Mailman import Utils
 from Mailman.i18n import _
 
 
  
 
- Transcript of session follows -
 PYTHONPATH /usr/local/mailman
 AGENT sendmail
 before = /usr/local/mailman/scripts
 before = /usr/local/mailman
 before = /usr/local/lib/python24.zip
 before = /usr/local/lib/python2.4/
 before = /usr/local/lib/python2.4/plat-sunos5
 before = /usr/local/lib/python2.4/lib-tk
 before = /usr/local/lib/python2.4/lib-dynload
 after = /usr/local/mailman/pythonlib
 after = /usr/local/mailman
 after = /usr/local/mailman/scripts
 after = /usr/local/mailman
 after = /usr/local/lib/python24.zip
 after = /usr/local/lib/python2.4/
 after = /usr/local/lib/python2.4/plat-sunos5
 after = /usr/local/lib/python2.4/lib-tk
 after = /usr/local/lib/python2.4/lib-dynload
 after = /usr/local/lib/python2.4/site-packages
 Traceback (most recent call last):
   File /usr/local/mailman/scripts/admin, line 42, in ?
 from Mailman.Queue.sbcache import get_switchboard
   File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
 from Mailman.Queue.Switchboard import Switchboard
   File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in ?
 from Mailman.Logging.Syslog import syslog
   File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
 from Mailman.Logging.StampedLogger import StampedLogger
   File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20, in ?
 from Mailman.Logging.Logger import Logger
   File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
 from Mailman.Logging.Utils import _logexc
   File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
 import traceback
 ImportError: No module named traceback
 554 5.3.0 unknown mailer error 1
 
 Oddly, the correct path statement is the only one with a trailing slash.


Have we eliminated the possibility that--due to some unfortunate
event--there really is no traceback module (or it can't be read)?

What do you get from
ls -l /usr/local/lib/python2.4/traceback.py

If it is there, does that file have world read permission?

Do you have multiple Python versions installed?

  --John


--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-19 Thread Dan Szkola
John W. Baxter wrote:

On 10/19/05 11:14 AM, Dan Szkola [EMAIL PROTECTED] wrote:

  

Mark Sapiro wrote:



Dan Szkola wrote:

 

  

Patched the admin script as suggested. When I saw the error this
morning, I emailed
to the admin address of our test list. Here is what I got:

 - Transcript of session follows -
PYTHONPATH /usr/local/mailman
   



I wouldn't have expected this, but I don't think it should matter.

What do you get if you add to the patch as follows

--- admin   2005-10-14 16:31:42.078125000 -0700
+++ admin_patched   2005-10-19 10:21:51.328125000 -0700
@@ -25,8 +25,16 @@


import sys
+from os import environ
+for env_var in environ:
+print env_var, environ[env_var]
+for s_path in sys.path:
+print 'before =', s_path

import paths
+for s_path in sys.path:
+print 'after =', s_path
+
from Mailman import mm_cfg
from Mailman import Utils
from Mailman.i18n import _


 

  

   - Transcript of session follows -
PYTHONPATH /usr/local/mailman
AGENT sendmail
before = /usr/local/mailman/scripts
before = /usr/local/mailman
before = /usr/local/lib/python24.zip
before = /usr/local/lib/python2.4/
before = /usr/local/lib/python2.4/plat-sunos5
before = /usr/local/lib/python2.4/lib-tk
before = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/mailman/pythonlib
after = /usr/local/mailman
after = /usr/local/mailman/scripts
after = /usr/local/mailman
after = /usr/local/lib/python24.zip
after = /usr/local/lib/python2.4/
after = /usr/local/lib/python2.4/plat-sunos5
after = /usr/local/lib/python2.4/lib-tk
after = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/lib/python2.4/site-packages
Traceback (most recent call last):
  File /usr/local/mailman/scripts/admin, line 42, in ?
from Mailman.Queue.sbcache import get_switchboard
  File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
from Mailman.Queue.Switchboard import Switchboard
  File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in ?
from Mailman.Logging.Syslog import syslog
  File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
from Mailman.Logging.StampedLogger import StampedLogger
  File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20, in ?
from Mailman.Logging.Logger import Logger
  File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
from Mailman.Logging.Utils import _logexc
  File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

Oddly, the correct path statement is the only one with a trailing slash.




Have we eliminated the possibility that--due to some unfortunate
event--there really is no traceback module (or it can't be read)?

What do you get from
ls -l /usr/local/lib/python2.4/traceback.py

If it is there, does that file have world read permission?

Do you have multiple Python versions installed?

  --John
  

Yep. If it didn't exist or was unreadable, wouldn't the script bail under
 normal circumstances?

Anyway, here is the output of an ls -l /usr/local/lib/python2.4/tr*:

-rw-r--r--   1 bin  bin28935 May 27 11:59 
/usr/local/lib/python2.4/trace.py
-rw-r--r--   1 bin  bin22092 May 27 12:01 
/usr/local/lib/python2.4/trace.pyc
-rw-r--r--   1 bin  bin22030 May 27 12:01 
/usr/local/lib/python2.4/trace.pyo
-rw-r--r--   1 bin  bin10464 May 27 11:59 
/usr/local/lib/python2.4/traceback.py
-rw-r--r--   1 bin  bin11030 May 27 12:01 
/usr/local/lib/python2.4/traceback.pyc
-rw-r--r--   1 bin  bin11030 May 27 12:01 
/usr/local/lib/python2.4/traceback.pyo

I have also tried copying the traceback.py file into various places that 
make sense and I
get the same error. I know it is getting read because it gets compiled 
into a .pyc file.

The python 2.4.1 was compiled from source and is the only python version 
on the box.

--
Dan Szkola
Sr Unix Systems Programmer
Northern Illinois University
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-19 Thread Mark Sapiro
Dan Szkola wrote:

John W. Baxter wrote:

On 10/19/05 11:14 AM, Dan Szkola [EMAIL PROTECTED] wrote:

  

Mark Sapiro wrote:



Dan Szkola wrote:

 

  

Patched the admin script as suggested. When I saw the error this
morning, I emailed
to the admin address of our test list. Here is what I got:

 - Transcript of session follows -
PYTHONPATH /usr/local/mailman
   



I wouldn't have expected this, but I don't think it should matter.


A closer look reveals that this comes from the wrapper and thus is
always there.



What do you get if you add to the patch as follows

--- admin   2005-10-14 16:31:42.078125000 -0700
+++ admin_patched   2005-10-19 10:21:51.328125000 -0700
@@ -25,8 +25,16 @@


import sys
+from os import environ
+for env_var in environ:
+print env_var, environ[env_var]
+for s_path in sys.path:
+print 'before =', s_path

import paths
+for s_path in sys.path:
+print 'after =', s_path
+
from Mailman import mm_cfg
from Mailman import Utils
from Mailman.i18n import _


 

  

   - Transcript of session follows -
PYTHONPATH /usr/local/mailman
AGENT sendmail
before = /usr/local/mailman/scripts
before = /usr/local/mailman
before = /usr/local/lib/python24.zip
before = /usr/local/lib/python2.4/
before = /usr/local/lib/python2.4/plat-sunos5
before = /usr/local/lib/python2.4/lib-tk
before = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/mailman/pythonlib
after = /usr/local/mailman
after = /usr/local/mailman/scripts
after = /usr/local/mailman
after = /usr/local/lib/python24.zip
after = /usr/local/lib/python2.4/
after = /usr/local/lib/python2.4/plat-sunos5
after = /usr/local/lib/python2.4/lib-tk
after = /usr/local/lib/python2.4/lib-dynload
after = /usr/local/lib/python2.4/site-packages
Traceback (most recent call last):
  File /usr/local/mailman/scripts/admin, line 42, in ?
from Mailman.Queue.sbcache import get_switchboard
  File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
from Mailman.Queue.Switchboard import Switchboard
  File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in ?
from Mailman.Logging.Syslog import syslog
  File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
from Mailman.Logging.StampedLogger import StampedLogger
  File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20, in ?
from Mailman.Logging.Logger import Logger
  File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
from Mailman.Logging.Utils import _logexc
  File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

Oddly, the correct path statement is the only one with a trailing slash.
 


This shouldn't be a problem. I tried adding the slash in my Python
2.4.1 and it didn't matter.

   



Have we eliminated the possibility that--due to some unfortunate
event--there really is no traceback module (or it can't be read)?

What do you get from
ls -l /usr/local/lib/python2.4/traceback.py

If it is there, does that file have world read permission?

Do you have multiple Python versions installed?

  --John
  

Yep. If it didn't exist or was unreadable, wouldn't the script bail under
 normal circumstances?


Yes, unless somehow it becomes unreadable and restarting sendmail makes
it readable again. That's too scary to even think about.


Anyway, here is the output of an ls -l /usr/local/lib/python2.4/tr*:

-rw-r--r--   1 bin  bin28935 May 27 11:59 
/usr/local/lib/python2.4/trace.py
-rw-r--r--   1 bin  bin22092 May 27 12:01 
/usr/local/lib/python2.4/trace.pyc
-rw-r--r--   1 bin  bin22030 May 27 12:01 
/usr/local/lib/python2.4/trace.pyo
-rw-r--r--   1 bin  bin10464 May 27 11:59 
/usr/local/lib/python2.4/traceback.py
-rw-r--r--   1 bin  bin11030 May 27 12:01 
/usr/local/lib/python2.4/traceback.pyc
-rw-r--r--   1 bin  bin11030 May 27 12:01 
/usr/local/lib/python2.4/traceback.pyo

I have also tried copying the traceback.py file into various places that 
make sense and I
get the same error. I know it is getting read because it gets compiled 
into a .pyc file.


The implications of this are also too scary to think about.


The python 2.4.1 was compiled from source and is the only python version 
on the box.

In a later post, you say it wasn't, but you removed the Sun Gnome
Python 2.3. I hope that fixes it, but I doubt it will.

Here's something else to try if it fails again. As the mailman user in
the /usr/local/mailman directory, give the command

python2.4 -S /usr/local/mailman/scripts/admin listname file

where listname is the name of the list and file contains an arbitrary
rfc822-like message. It can be as simple as

-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: test

body


Except for the fact that this doesn't edit the environment passed to
the script, 

Re: [Mailman-Users] Strange errors

2005-10-18 Thread Dan Szkola
Mark Sapiro wrote:

Dan Szkola wrote:
  

I am running a Solaris 10 box, with mailman-2.1.6rc4 and sendmail
version 8.13.3. Python version is 2.4.1.

I run sendmail in the following ways:


A normal sendmail daemon listening on port 25:

/usr/lib/sendmail -bd -q15m

A persistent queue runner:

/usr/lib/sendmail -qp1m -OPidFile=/var/run/sendmail-qrun.pid

A sendmail with submit.cf config:

/usr/lib/sendmail -Ac -q5m

A sendmail for smtp-auth listening on port 587:

/usr/lib/sendmail -bd -C/etc/mail/sendmail-auth.cf -q15m


Anyway, the problem we are having is this:

 After running for several days with no errors, we suddenly start
 seeing this error:



Mail Delivery Subsystem [EMAIL PROTECTED]
  

10/17/2005 9:18:52 AM 
The original message was received at Mon, 17 Oct 2005 09:18:21 -0500
(CDT)


from .xxx.xxx.xxx [131.156.xxx.xxx]
  

  - The following addresses had permanent fatal errors -
|/usr/local/mailman/mail/mailman post testlist
   (reason: 1)
   (expanded from: [EMAIL PROTECTED])

  - Transcript of session follows -
Traceback (most recent call last):
 File /usr/local/mailman/scripts/post, line 35, in ?
   from Mailman.Queue.sbcache import get_switchboard
 File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
   from Mailman.Queue.Switchboard import Switchboard
 File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in
?
   from Mailman.Logging.Syslog import syslog
 File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
   from Mailman.Logging.StampedLogger import StampedLogger
 File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20,
in ?
   from Mailman.Logging.Logger import Logger
 File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
   from Mailman.Logging.Utils import _logexc
 File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
   import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

Has anyone seen this? Should I file a bug on this or send it along
to the developers list?

Restarting sendmail seems to get rid of the problem for a day or two.
All sendmail configs have the mailman alias file included and we run
newaliases to update it on every new list creation.




This is curious indeed for at least two reasons.

It is not a sendmail alias problem, nor does it seem on the face to be
a sendmail problem at all. The post is received by sendmail and piped
to the wrapper with the appropriate arguments. The wrapper invokes the
post script as it should.

The post script then does some imports one of which is
from Mailman.Queue.sbcache import get_switchboard

sbcache does
from Mailman.Queue.Switchboard import Switchboard

and so on until Mailman.Logging.Utils does
import traceback

which results in ImportError: No module named traceback

Now this is really strange because traceback is a Python library module
and this chain of imports leading to 'import traceback' occurs with
every post, so why does it fail now and why does restarting sendmail
fix it?
  

I built Python from source on a Solaris 10 box. Could it be a problem 
with the
way it was built? I'm doubting it, but I don't use python all that often.

What happens if you restart Mailman (bin/mailmanctl restart) without
restarting sendmail? Does that fix it? Or do all the qrunners die with
the same ImportError?
  

I was just notified by our helpdesk that it is failing again. I will 
restart only mailman
and see if that fixes the issue.

I have no reason other than superstition for the following suggestion,
but try

SMTP_MAX_SESSIONS_PER_CONNECTION = 1

in mm_cfg.py and see if that helps. This will cause Mailman to close
the SMTP connection to sendmail after each transaction. This might
avoid the problem, but since I have no idea what the problem is, I
have no idea if this will help.
  

I'll try that after a while as well.

Is there somewhere I can enable more debugging to help get to the bottom of
this issue? I'm finding next to nothing in the logs that is helpful.

--
Dan Szkola
Sr Unix Systems Programmer
Northern Illinois University

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-18 Thread Brad Knowles
At 8:37 AM -0500 2005-10-18, Dan Szkola wrote:

  Is there somewhere I can enable more debugging to help get to the bottom of
  this issue? I'm finding next to nothing in the logs that is helpful.

There is no additional debugging that can be enabled.  Assuming 
you're looking in the right places, you're already seeing everything 
that is available.

You can always put in additional code to create additional 
debugging that you may find useful, but that's about it.  If you 
decide to go this route, you will need to be careful about 
indentation and other aspects of the Python programming language, 
otherwise you're likely to cause more damage than you're trying to 
cure.

-- 
Brad Knowles, [EMAIL PROTECTED]

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See http://www.sage.org/ for more info.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-18 Thread Dan Szkola
Mark Sapiro wrote:

Dan Szkola wrote:
  

I am running a Solaris 10 box, with mailman-2.1.6rc4 and sendmail
version 8.13.3. Python version is 2.4.1.

I run sendmail in the following ways:


A normal sendmail daemon listening on port 25:

/usr/lib/sendmail -bd -q15m

A persistent queue runner:

/usr/lib/sendmail -qp1m -OPidFile=/var/run/sendmail-qrun.pid

A sendmail with submit.cf config:

/usr/lib/sendmail -Ac -q5m

A sendmail for smtp-auth listening on port 587:

/usr/lib/sendmail -bd -C/etc/mail/sendmail-auth.cf -q15m


Anyway, the problem we are having is this:

 After running for several days with no errors, we suddenly start
 seeing this error:



Mail Delivery Subsystem [EMAIL PROTECTED]
  

10/17/2005 9:18:52 AM 
The original message was received at Mon, 17 Oct 2005 09:18:21 -0500
(CDT)


from .xxx.xxx.xxx [131.156.xxx.xxx]
  

  - The following addresses had permanent fatal errors -
|/usr/local/mailman/mail/mailman post testlist
   (reason: 1)
   (expanded from: [EMAIL PROTECTED])

  - Transcript of session follows -
Traceback (most recent call last):
 File /usr/local/mailman/scripts/post, line 35, in ?
   from Mailman.Queue.sbcache import get_switchboard
 File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
   from Mailman.Queue.Switchboard import Switchboard
 File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in
?
   from Mailman.Logging.Syslog import syslog
 File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
   from Mailman.Logging.StampedLogger import StampedLogger
 File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20,
in ?
   from Mailman.Logging.Logger import Logger
 File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
   from Mailman.Logging.Utils import _logexc
 File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
   import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

Has anyone seen this? Should I file a bug on this or send it along
to the developers list?

Restarting sendmail seems to get rid of the problem for a day or two.
All sendmail configs have the mailman alias file included and we run
newaliases to update it on every new list creation.




This is curious indeed for at least two reasons.

It is not a sendmail alias problem, nor does it seem on the face to be
a sendmail problem at all. The post is received by sendmail and piped
to the wrapper with the appropriate arguments. The wrapper invokes the
post script as it should.

The post script then does some imports one of which is
from Mailman.Queue.sbcache import get_switchboard

sbcache does
from Mailman.Queue.Switchboard import Switchboard

and so on until Mailman.Logging.Utils does
import traceback

which results in ImportError: No module named traceback

Now this is really strange because traceback is a Python library module
and this chain of imports leading to 'import traceback' occurs with
every post, so why does it fail now and why does restarting sendmail
fix it?

What happens if you restart Mailman (bin/mailmanctl restart) without
restarting sendmail? Does that fix it? Or do all the qrunners die with
the same ImportError?
  

I restarted only the mailman processes using bin/mailmanctl restart and 
post still
generate the error above. I will put the line below into the mm_cfg.py 
file and
restart sendmail and watch what happens.

I have no reason other than superstition for the following suggestion,
but try

SMTP_MAX_SESSIONS_PER_CONNECTION = 1

in mm_cfg.py and see if that helps. This will cause Mailman to close
the SMTP connection to sendmail after each transaction. This might
avoid the problem, but since I have no idea what the problem is, I
have no idea if this will help.

  


--
Dan Szkola
Sr Unix Systems Programmer
Northern Illinois University

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-18 Thread Mark Sapiro
Dan Szkola wrote (in separate posts):

Is there somewhere I can enable more debugging to help get to the bottom of
this issue? I'm finding next to nothing in the logs that is helpful.


As Brad replied, there are no debugging switches, but I'm not sure that
this would be helpful in this case anyway. The traceback you get in
sendmail's DSN tells us what happens, and the why doesn't seem to be
Mailman. Also, the error occurs in the import of the logging module so
there is a catch 22 in trying to log information about the error.

Next time this occurs, you could look to see if Python's traceback.py
is actually in the library. Normally, there will be a traceback.py,
traceback.pyc and traceback.pyo in /usr/lib/python2.4, but only the
traceback.py should be necessary. The others are compiled versions
that will be (re)created as needed.


I restarted only the mailman processes using bin/mailmanctl restart and 
post still
generate the error above.


This is further confirmation that the problem isn't Mailman per se. The
only thing I can think is that somehow something that affects Python
is being set by sendmail in the environment that it passes to the
wrapper, and that this only happens after a number of posts.
Environment variables that affect Python should begin with 'PYTHON'
and are described on the python man page.

You could try the following patch to the $prefix/scripts/post script to
print the environment each time it is invoked. Assuming sendmail
doesn't choke on this in the normal case, it should appear in the DSN
in the error case.

Patch-
--- scripts/post2005-10-14 16:31:41.93750 -0700
+++ scripts/post_patched2005-10-18 12:14:18.03125 -0700
@@ -27,6 +27,9 @@
 

 import sys
+from os import environ
+for env_var in environ:
+print env_var, environ[env_var]

 import paths
 from Mailman import mm_cfg
End Patch-

Perhaps a better plan would be to patch the $prefix/scripts/admin
script instead (same patch). Presumably mail to the listname-admin
address will bounce the same way when the problem occurs because it
begins with the same imports, but listname-admin is a deprecated name
and shouldn't be receiving mail normally, so patching the admin script
and sending mail to listname-admin should get the information you want
in the DSN without possibly choking sendmail in the 'normal' case.

I will put the line below into the mm_cfg.py 
file and
restart sendmail and watch what happens.

I have no reason other than superstition for the following suggestion,
but try

SMTP_MAX_SESSIONS_PER_CONNECTION = 1

in mm_cfg.py and see if that helps. This will cause Mailman to close
the SMTP connection to sendmail after each transaction. This might
avoid the problem, but since I have no idea what the problem is, I
have no idea if this will help.


OK. Let us know.

-- 
Mark Sapiro [EMAIL PROTECTED]   The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


[Mailman-Users] Strange errors

2005-10-17 Thread Dan Szkola
Hello all,

We are converting our lists from a different list server to mailman.

I am running a Solaris 10 box, with mailman-2.1.6rc4 and sendmail
version 8.13.3. Python version is 2.4.1.

I run sendmail in the following ways:


A normal sendmail daemon listening on port 25:

/usr/lib/sendmail -bd -q15m

A persistent queue runner:

/usr/lib/sendmail -qp1m -OPidFile=/var/run/sendmail-qrun.pid

A sendmail with submit.cf config:

/usr/lib/sendmail -Ac -q5m

A sendmail for smtp-auth listening on port 587:

/usr/lib/sendmail -bd -C/etc/mail/sendmail-auth.cf -q15m


Anyway, the problem we are having is this:

  After running for several days with no errors, we suddenly start
  seeing this error:

 Mail Delivery Subsystem [EMAIL PROTECTED]
10/17/2005 9:18:52 AM 
The original message was received at Mon, 17 Oct 2005 09:18:21 -0500
(CDT)
from .xxx.xxx.xxx [131.156.xxx.xxx]

   - The following addresses had permanent fatal errors -
|/usr/local/mailman/mail/mailman post testlist
(reason: 1)
(expanded from: [EMAIL PROTECTED])

   - Transcript of session follows -
Traceback (most recent call last):
  File /usr/local/mailman/scripts/post, line 35, in ?
from Mailman.Queue.sbcache import get_switchboard
  File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
from Mailman.Queue.Switchboard import Switchboard
  File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in
?
from Mailman.Logging.Syslog import syslog
  File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
from Mailman.Logging.StampedLogger import StampedLogger
  File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20,
in ?
from Mailman.Logging.Logger import Logger
  File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
from Mailman.Logging.Utils import _logexc
  File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

Has anyone seen this? Should I file a bug on this or send it along
to the developers list?

Restarting sendmail seems to get rid of the problem for a day or two.
All sendmail configs have the mailman alias file included and we run
newaliases to update it on every new list creation.

--
Dan Szkola


--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp


Re: [Mailman-Users] Strange errors

2005-10-17 Thread Mark Sapiro
Dan Szkola wrote:

I am running a Solaris 10 box, with mailman-2.1.6rc4 and sendmail
version 8.13.3. Python version is 2.4.1.

I run sendmail in the following ways:


A normal sendmail daemon listening on port 25:

/usr/lib/sendmail -bd -q15m

A persistent queue runner:

/usr/lib/sendmail -qp1m -OPidFile=/var/run/sendmail-qrun.pid

A sendmail with submit.cf config:

/usr/lib/sendmail -Ac -q5m

A sendmail for smtp-auth listening on port 587:

/usr/lib/sendmail -bd -C/etc/mail/sendmail-auth.cf -q15m


Anyway, the problem we are having is this:

  After running for several days with no errors, we suddenly start
  seeing this error:

 Mail Delivery Subsystem [EMAIL PROTECTED]
10/17/2005 9:18:52 AM 
The original message was received at Mon, 17 Oct 2005 09:18:21 -0500
(CDT)
from .xxx.xxx.xxx [131.156.xxx.xxx]

   - The following addresses had permanent fatal errors -
|/usr/local/mailman/mail/mailman post testlist
(reason: 1)
(expanded from: [EMAIL PROTECTED])

   - Transcript of session follows -
Traceback (most recent call last):
  File /usr/local/mailman/scripts/post, line 35, in ?
from Mailman.Queue.sbcache import get_switchboard
  File /usr/local/mailman/Mailman/Queue/sbcache.py, line 19, in ?
from Mailman.Queue.Switchboard import Switchboard
  File /usr/local/mailman/Mailman/Queue/Switchboard.py, line 47, in
?
from Mailman.Logging.Syslog import syslog
  File /usr/local/mailman/Mailman/Logging/Syslog.py, line 22, in ?
from Mailman.Logging.StampedLogger import StampedLogger
  File /usr/local/mailman/Mailman/Logging/StampedLogger.py, line 20,
in ?
from Mailman.Logging.Logger import Logger
  File /usr/local/mailman/Mailman/Logging/Logger.py, line 25, in ?
from Mailman.Logging.Utils import _logexc
  File /usr/local/mailman/Mailman/Logging/Utils.py, line 18, in ?
import traceback
ImportError: No module named traceback
554 5.3.0 unknown mailer error 1

Has anyone seen this? Should I file a bug on this or send it along
to the developers list?

Restarting sendmail seems to get rid of the problem for a day or two.
All sendmail configs have the mailman alias file included and we run
newaliases to update it on every new list creation.


This is curious indeed for at least two reasons.

It is not a sendmail alias problem, nor does it seem on the face to be
a sendmail problem at all. The post is received by sendmail and piped
to the wrapper with the appropriate arguments. The wrapper invokes the
post script as it should.

The post script then does some imports one of which is
from Mailman.Queue.sbcache import get_switchboard

sbcache does
from Mailman.Queue.Switchboard import Switchboard

and so on until Mailman.Logging.Utils does
import traceback

which results in ImportError: No module named traceback

Now this is really strange because traceback is a Python library module
and this chain of imports leading to 'import traceback' occurs with
every post, so why does it fail now and why does restarting sendmail
fix it?

What happens if you restart Mailman (bin/mailmanctl restart) without
restarting sendmail? Does that fix it? Or do all the qrunners die with
the same ImportError?

I have no reason other than superstition for the following suggestion,
but try

SMTP_MAX_SESSIONS_PER_CONNECTION = 1

in mm_cfg.py and see if that helps. This will cause Mailman to close
the SMTP connection to sendmail after each transaction. This might
avoid the problem, but since I have no idea what the problem is, I
have no idea if this will help.

-- 
Mark Sapiro [EMAIL PROTECTED]   The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp