You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Barry Pederson <bp...@barryp.org> on 2003/08/17 17:20:23 UTC
Session/mutex problem
Gregory (Grisha) Trubetskoy wrote:
> I just added another snapshot
>
> http://www.modpython.org/tmp/httpd-python-20030814.tgz
>
> and also the latest compilation of the html docs:
>
> http://www.modpython.org/tmp/doc-html-20030814/
>
> Now you have no excuse for not checking it out :-)
I was checking this out on a FreeBSD 5.1 box, with Apache 2.0.47 using
the prefork MPM, and with the "User www" directive in httpd.conf. When
trying to use the new session code, got the exception:
---------
File "/usr/local/lib/python2.3/site-packages/mod_python/Session.py",
line 342, in do_load
_apache._global_lock(self._req.server, None, 0)
ValueError: Failed to acquire global mutex lock
---------
Looking at the httpd-error.log, I found:
-----------
[Sun Aug 17 10:04:16 2003] [notice] mod_python: Creating 256 session
mutexes based on 256 max processes and 0 max threads.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx191750.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx191750.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx191750.
------------
(modutex? typo there)
Looking in the /tmp folder, I found the mutex files with permissions
such as:
-rw------- 1 root wheel 0 Aug 17 10:04 mpmtx191750
So...I'm guessing the mutex files are created before apache forks and
switches from the "root" user to the "www" user, and can't access those
files?
Barry
Re: Session/mutex problem
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
I forgot to mention that this issues should be resolved now (apparently I
was using the wrong pool to allocate global_mutex, so they weren't getting
cleaned up on graceful restarts).
Also, thanks to Thom May we now have CVS snapshots:
http://cvs.apache.org/snapshots/httpd-python/
Grisha
On Sun, 17 Aug 2003, Barry Pederson wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
> > I'll check it out on my FreeBSD 4.8 box.
> >
> > Thanks, BTW, for trying it out - we need more problem reports like this
> > :-)
>
> While poking around to see what could be done about this, I found an
> even simpler failure trigger ... under my config as described before
> (FreeBSD 5.1 Apache 2.0.47, Python 2.3, prefork MPM, start as user
> "root" switching to "www"), just starting apache (apachectl start),
> gives this in the httpd-error.log
>
> ------------
> [Sun Aug 17 12:18:22 2003] [notice] mod_python: Creating 256 session
> mutexes based on 256 max processes and 0 max threads.
> [Sun Aug 17 12:18:22 2003] [notice] Apache configured -- resuming normal
> operations
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> --------------
>
>
> And then doing a graceful restart (apachectl graceful) give this
>
> ---------------
> [Sun Aug 17 12:18:46 2003] [notice] Graceful restart requested, doing
> restart
> [Sun Aug 17 12:18:46 2003] [notice] mod_python: Creating 256 session
> mutexes based on 256 max processes and 0 max threads.
> [Sun Aug 17 12:18:46 2003] [error] (17)File exists: mod_python: Failed
> to create global mutex 0 of 256 (/tmp/mpmtx948550).
> Configuration Failed
> ----------------
>
> and then all the httpd processes quit. You don't even have to request
> any mod-python handled pages :(
>
> Barry
>
Re: Session timeout problem
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Yes, I think adding a self.clear() after self.do_delete() (line 240) would
do it.
P.S. I'm still trying to figure out the graceful restart problem.
Grisha
On Sun, 17 Aug 2003, Barry Pederson wrote:
> This is an easy one...
>
> In the snapshot http://www.modpython.org/tmp/httpd-python-20030814.tgz
> the BaseSession.__init__() method checks for a session timing out, and
> if it's expired, it makes a new session. However, the old session's
> data is still hanging around and is carried over into the new session.
>
> There probably should be a call to self.clear() somewhere in there,
> perhaps at the end of Session.delete()?
>
> Here's a bit of demo code. Every time you reload the page, the count
> stored in the session increases by one, even if you wait longer than 30
> seconds and have a new session created.
>
> ----------------
> import time
> from mod_python.Session import Session
>
> def index(req):
> sess = Session(req)
> count = sess.get('count', 0) + 1
> sess['count'] = count
> sess.set_timeout(30)
> sess.save()
> return 'is_new(): %d count: %d, time: %s' % (sess.is_new(), count,
> time.strftime('%Y-%m-%d %H:%M:%S'))
> -----------------
>
> Barry
>
Session timeout problem
Posted by Barry Pederson <bp...@barryp.org>.
This is an easy one...
In the snapshot http://www.modpython.org/tmp/httpd-python-20030814.tgz
the BaseSession.__init__() method checks for a session timing out, and
if it's expired, it makes a new session. However, the old session's
data is still hanging around and is carried over into the new session.
There probably should be a call to self.clear() somewhere in there,
perhaps at the end of Session.delete()?
Here's a bit of demo code. Every time you reload the page, the count
stored in the session increases by one, even if you wait longer than 30
seconds and have a new session created.
----------------
import time
from mod_python.Session import Session
def index(req):
sess = Session(req)
count = sess.get('count', 0) + 1
sess['count'] = count
sess.set_timeout(30)
sess.save()
return 'is_new(): %d count: %d, time: %s' % (sess.is_new(), count,
time.strftime('%Y-%m-%d %H:%M:%S'))
-----------------
Barry
Re: Session/mutex problem
Posted by Barry Pederson <bp...@barryp.org>.
Gregory (Grisha) Trubetskoy wrote:
> I'll check it out on my FreeBSD 4.8 box.
>
> Thanks, BTW, for trying it out - we need more problem reports like this
> :-)
While poking around to see what could be done about this, I found an
even simpler failure trigger ... under my config as described before
(FreeBSD 5.1 Apache 2.0.47, Python 2.3, prefork MPM, start as user
"root" switching to "www"), just starting apache (apachectl start),
gives this in the httpd-error.log
------------
[Sun Aug 17 12:18:22 2003] [notice] mod_python: Creating 256 session
mutexes based on 256 max processes and 0 max threads.
[Sun Aug 17 12:18:22 2003] [notice] Apache configured -- resuming normal
operations
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
--------------
And then doing a graceful restart (apachectl graceful) give this
---------------
[Sun Aug 17 12:18:46 2003] [notice] Graceful restart requested, doing
restart
[Sun Aug 17 12:18:46 2003] [notice] mod_python: Creating 256 session
mutexes based on 256 max processes and 0 max threads.
[Sun Aug 17 12:18:46 2003] [error] (17)File exists: mod_python: Failed
to create global mutex 0 of 256 (/tmp/mpmtx948550).
Configuration Failed
----------------
and then all the httpd processes quit. You don't even have to request
any mod-python handled pages :(
Barry
Re: Session/mutex problem
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Sun, 17 Aug 2003, Barry Pederson wrote:
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx191750.
> ------------
> (modutex? typo there)
Probabaly just my fat-fingering :-)
>
>
> Looking in the /tmp folder, I found the mutex files with permissions
> such as:
>
> -rw------- 1 root wheel 0 Aug 17 10:04 mpmtx191750
>
> So...I'm guessing the mutex files are created before apache forks and
> switches from the "root" user to the "www" user, and can't access those
> files?
That's weird - its the APR that creates the file, I'd imagine it should
set the permissions correctly... I never ran into this, but then I always
did all my testing as a non-root user, so the server never switched the
uid.
I'll check it out on my FreeBSD 4.8 box.
Thanks, BTW, for trying it out - we need more problem reports like this
:-)
Grisha