[mod_python] sys.path problem

Graham Dumpleton graham.dumpleton at gmail.com
Thu Feb 21 00:49:39 EST 2008


On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote:
> Hi Graham,
>
> Actually I have a separate module called Path that handles the sys.path
> tomfoolery.  It basically reads in a text file where each line is a path I
> want to append to sys.path, and does the appending for me.  In that file I
> do have the path to the module directory listed explicitly.  I've removed
> that and it still seems to be broken to the same extent (not worse).  Yay.
>
>
> Something else I just noticed...watching the logs as I replicate this
> condition, I'm logging sys.path explicitly at the top of my handlerA module,
> right after I import mod_python stuff and my Path module.  What's
> interesting is that it doesn't always log there.  It's as if some of the
> requests being handled re-use the same handler instance- which is great
> because I'm sure this is giving me the performance boost that I want from
> mod_python. (That should answer your question about "why mod_python".
> Basically, CGI is too slow for what I need to handle).

No it doesn't really answer my question. The mod_python module isn't
the only module for Apache/Python stuff anymore. If your code wasn't
heavily bound to mod_python specific features and could be modified to
be a WSGI application you could use mod_wsgi instead. I am more
confident in mod_wsgi not having problems with multiple VirtualHost
that mod_python some times seems to have.

> So the first time a new handlerA instance is created after the first
> handlerB instance is created, the sys.path that gets logged for handlerA
> shows me what I know handlerB is setting it to.  The odd thing is, it
> doesn't go both ways.  I can invoke one or the other first after an apache
> restart, the sequence isn't important.  handlerA is the only one that seems
> to suffer this fate.
>
> I tried to modify my VirtualHost configurations to use the .testhandler
> thing but it didn't work.  I'm not sure if you saw, but I'm using SetHandler
> mod_python and then PythonHandler handlerA.  I tried changing it to
> SetHandler mod_python.testhandler but then that broke everything.  I started
> getting 404's.  Is that expected?  I wouldn't think so...

I said to use:

  PythonHandler mod_python.testhandler

not use SetHandler. I want you to replace your handler with this test handler.

Have you dumped out mod_python.apache.interpreter yet and seen whether
it is correct for each application?

Graham

> On Thu, Feb 21, 2008 at 12:25 AM, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
> >
> > On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote:
> > > Hi Graham,
> > >
> >
> > > I wonder if this is a useful piece of information.  I just noticed this
> in
> > > my logs:
> > >
> > > [Wed Feb 20 23:02:46 2008] [warn] mod_python (pid=29597,
> > > interpreter='InterpB'): Module directory listed in "sys.path". This may
> > > cause problems. Please check code. File being imported is
> > > "/var/handlerB/www/handlerB_root/ProjectModule.py".
> > >
> > > I'm not sure I understand what it's complaining about?
> >
> > The new module importer underlaying import_module() and as also used
> > by Python*Handler tries to keep mod_python module importer path
> > separate from sys.path. This is because an overlap can cause problems
> > with modules load duplicate times. You must be explicitly adding the
> > document directory to sys.path in your script, which you shouldn't do.
> >
> > Can you show first part of script where you set sys.path.
> >
> > Graham
> >
> >
> >
> >
> > >
> > > -aj
> > >
> > >
> > >
> > >
> > > On Wed, Feb 20, 2008 at 9:41 PM, Graham Dumpleton
> > > <graham.dumpleton at gmail.com> wrote:
> > >
> > > >
> > > > On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote:
> > > >
> > > > > Hi Graham,
> > > > >
> > > > > I'm not using PythonPath anywhere, though my handlers both make
> > > > > sys.path.append() calls to add various library paths needed by each.
> > > > > Inconveniently, each of these handlers use different versions of
> some of
> > > the
> > > > > same libraries.  It's a bit of a mess, but this all worked fine on
> > > 3.1.3.
> > > > > Now that I upgraded to 3.3.1 (and changed nothing else), it's
> broken.
> > > > > Rolling back seems the obvious choice, but I think what I'm trying
> to do
> > > > > *is* do-able, no?
> > > >
> > > > As per the documentation I pointed out, try setting:
> > > >
> > > >  PythonOption mod_python.legacy.importer name
> > > >
> > > > this will restore the old module importer functionality. If it still
> > > > doesn't work, possibly something in Apache configuration causing
> > > > issues instead.
> > > >
> > > > In principle I can't see a problem with what you are trying to do,
> > > > although see comments below.
> > > >
> > > >
> > > > > As you requested, I have included my configuration below.  I'm just
> > > > > developing on a workstation and DNS is managed by /etc/hosts, hence
> the
> > > > > .localdomain host names.  Without further adieu:
> > > >
> > > > Do those names map to distinct IP addresses or the same?
> > > >
> > > > In Apache documentation it doesn't recommend that you use FQDN in
> > > > VirtualHost argument, but an IP address. Ie., in:
> > > >
> > > >
> > >
> http://httpd.apache.org/docs/2.2/mod/core.html#virtualhost
> > > >
> > > > It says:
> > > >
> > > >  """A fully qualified domain name for the IP address of the virtual
> > > > host (not recommended)"""
> > > >
> > > > The ServerName within the VirtualHost is what actually distinguishes
> > > > them if using name based lookup against the same IP address.
> > > >
> > > > If using IPs or names rather than just *:80 then NameVirtualHost isn't
> > > > required, but there have been cases where lack of NameVirtualHost in
> > > > Apache configuration has caused mod_python to somehow merge sites when
> > > > it shouldn't have been. Not know whether this is a bug in mod_python
> > > > or not as when people got it working by adding NameVirtualHost, they
> > > > were then interested in helping to debug the underlying problem.
> > > >
> > > >
> > > > > aj at aj-5150:~$ cat /var/handlerA/www/.htaccess
> > > > > PythonInterpreter InterpA
> > > > > Options -Indexes
> > > > >
> > > > > aj at aj-5150:~$ cat /var/handlerB/www/.htaccess
> > > > >  PythonInterpreter InterpB
> > > > > Options -Indexes
> > > >
> > > > Have you confirmed that the .htaccess files are in fact being
> > > > consulted. You can do this by introducing a syntax error in them. Ie.,
> > > > add a line consisting of 'CRAP'. If when making request you then get a
> > > > 500 error they are being consulted. The lack of an AllowOverride for
> > > > the directories suggests they may not even be getting consulted and so
> > > > the PythonInterpreter directives may not be getting applied. This may
> > > > be combining with NameVirtualHost issues to end up with stuff running
> > > > in same interpreter.
> > > >
> > > > You can work out which interpreter code is running in by printing out
> > > > 'apache.interpreter' from mod_python module.
> > > >
> > > > Graham
> > > >
> > >
> > >
> >
>
>


More information about the Mod_python mailing list