Re: [modwsgi] ImportError: No module named trac.web.main

2,406 views
Skip to first unread message

Graham Dumpleton

unread,
Jul 2, 2012, 6:51:51 PM7/2/12
to mod...@googlegroups.com
Run 'ldd' on the mod_wsgi.so file.

It may be the case that mod_wsgi isn't compiled against the version of
Python you think it is.

So follow through and check things using steps detailed in:

http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Installation_In_Use

As a separate issue, consider using mod_wsgi daemon mode, else you
might find Trace taking up too much memory. See daemon mode examples
in:

http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process

Graham

On 3 July 2012 00:17, Williams <michael_p...@yahoo.com> wrote:
> Hello,
>
> Please let me start by saying that I am a Python, Apache, and wsgi newbe.  I
> have been at this for a couple of days and getting nowhere.  Any help would
> be greatly appreciated!
>
> I am attempting to get trac running with apache2 on linux 6.2 using python
> 2.6.6.  I have downloaded, compiled, and loaded mod_wsgi-3.3.  Note: I can
> successfully run the hello.wsgi script from a python command line.  It seems
> like my /usr/lib/python2.6/site-packages are not getting loaded from the
> Apache2 mod_wsgi?  I have done a chmod -R 777 to
> /usr/lib/python2.6/site-packages and '/opt/trac/projects.
>
> When I attempt to access http:/myhostname/trac I get the following error in
> the apache error.log:
>
> [Mon Jul 02 07:51:59 2012] [notice] Apache/2.2.15 (Unix) DAV/2 SVN/1.6.11
> mod_wsgi/3.3 Python/2.6.6 configured -- resuming normal operations
> [Mon Jul 02 07:52:03 2012] [error] [client ::1] mod_wsgi (pid=7865): Target
> WSGI script '/opt/trac/projects/ehawah/apache/hello.wsgi' cannot be loaded
> as Python module.
> [Mon Jul 02 07:52:03 2012] [error] [client ::1] mod_wsgi (pid=7865):
> Exception occurred processing WSGI script
> '/opt/trac/projects/ehawah/apache/hello.wsgi'.
> [Mon Jul 02 07:52:03 2012] [error] [client ::1] Traceback (most recent call
> last):
> [Mon Jul 02 07:52:03 2012] [error] [client ::1]   File
> "/opt/trac/projects/ehawah/apache/hello.wsgi", line 16, in <module>
> [Mon Jul 02 07:52:03 2012] [error] [client ::1]     import trac.web.main
> [Mon Jul 02 07:52:03 2012] [error] [client ::1] ImportError: No module named
> trac.web.main
>
>
> My httpd.conf looks like this:
>
> WSGIScriptAlias /trac /opt/trac/projects/ehawah/apache/hello.wsgi
>
> <Directory /opt/trac/projects/ehawah/apache>
>     WSGIApplicationGroup %{GLOBAL}
>     Order deny,allow
>     Allow from all
> </Directory>
>
> My /opt/trac/projects/ehawah/apache/hello.wsgi script contains the
> following:
>
> import sys
> import site
> import os
>
> file1  = open('/tmp/mpw.out', 'w', 0)
> sys.stdout = file1
> sys.stderr = file1
> print sys.version_info
> print 'mpw - sys.path1'
> print sys.path
>
> os.environ['TRAC_ENV'] = '/opt/trac/projects/ehawah'
> os.environ['PYTHON_EGG_CACHE'] = '/opt/trac/projects/eggs'
>
> import trac.web.main
>
> application = trac.web.main.dispatch_request
>
>
> Any help would be greatly appreciated!
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/modwsgi/-/4uoleRDl5QkJ.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to
> modwsgi+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.

Graham Dumpleton

unread,
Jul 2, 2012, 6:52:56 PM7/2/12
to mod...@googlegroups.com
One more thing. Don't override stdout/stderr like:

file1 = open('/tmp/mpw.out', 'w', 0)
sys.stdout = file1
sys.stderr = file1

It is not necessary. Output will go to Apache error log file.

Graham

Williams

unread,
Jul 3, 2012, 9:34:33 AM7/3/12
to mod...@googlegroups.com
Thanks for the fast response!


On 3 July 2012 08:51, Graham Dumpleton wrote:
> Run 'ldd' on the mod_wsgi.so file.
>
> It may be the case that mod_wsgi isn't compiled against the version of
> Python you think it is.
>
The output of ldd looks like this:
 [root@enoch modules]# ldd ./mod_wsgi.so
    linux-gate.so.1 =>  (0xb777e000)
    libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb75b1000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7596000)
    libdl.so.2 => /lib/libdl.so.2 (0xb7591000)
    libutil.so.1 => /lib/libutil.so.1 (0xb758d000)
    libm.so.6 => /lib/libm.so.6 (0xb7562000)
    libc.so.6 => /lib/libc.so.6 (0xb73d2000)
    /lib/ld-linux.so.2 (0x4f6be000)

My system did have some libpyglib-2.0-python.so libraries in /usr/lib.  To be certain that mod_wsgi was not picking them up I moved them to a temporary location and restarted apache.  It appears that I am running with the python 2.6 libraries.

The script provided in Python_Installation_In_Use shows something interesting but I am stumped on how to correct.  When running from apache the sys.path does not contain the following two packages, as root (command line) they are included in the sys.path.  Do you have any idea what may cause this?
'/usr/lib/python2.6/site-packages/Genshi-0.6-py2.6.egg'
'/usr/lib/python2.6/site-packages/Trac-0.12.3-py2.6.egg'

The sample script you provided in Python_Installation_In_Use provides the following information:
sys.version = '2.6.6 (r266:84292, Jun 18 2012, 09:13:53) \n[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)]'
sys.prefix = '/usr'
sys.path = ...
'/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg'
'/usr/lib/python2.6/site-packages/Babel-0.9.5-py2.6.egg'
'/usr/lib/python26.zip'
'/usr/lib/python2.6'
'/usr/lib/python2.6/plat-linux2'
'/usr/lib/python2.6/lib-tk'
'/usr/lib/python2.6/lib-old'
'/usr/lib/python2.6/lib-dynload'
'/usr/lib/python2.6/site-packages'
'/usr/lib/python2.6/site-packages/gst-0.10'
'/usr/lib/python2.6/site-packages/gtk-2.0'
'/usr/lib/python2.6/site-packages/webkit-1.0'
site.PREFIXES = ['/usr', '/usr']
site.ENABLE_USER_SITE = True
site.USER_SITE = '/var/www/.local/lib/python2.6/site-packages'

site.USER_BASE = '/var/www/.local'


> As a separate issue, consider using mod_wsgi daemon mode, else you
> might find Trace taking up too much memory. See daemon mode examples
> in:
>  
> http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
> http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process
>
This will be my next step.

I must be missing something simple?

Graham Dumpleton

unread,
Jul 3, 2012, 7:20:16 PM7/3/12
to mod...@googlegroups.com
On 3 July 2012 23:34, Williams <michael_p...@yahoo.com> wrote:
> The script provided in Python_Installation_In_Use shows something
> interesting but I am stumped on how to correct. When running from apache
> the sys.path does not contain the following two packages, as root (command
> line) they are included in the sys.path. Do you have any idea what may
> cause this?
> '/usr/lib/python2.6/site-packages/Genshi-0.6-py2.6.egg'
> '/usr/lib/python2.6/site-packages/Trac-0.12.3-py2.6.egg'

What is the output from running:

ls -las /usr/lib/python2.6/site-packages/

ls -las /usr/lib/python2.6/site-packages/Genshi-0.6-py2.6.egg
ls -las /usr/lib/python2.6/site-packages/Trac-0.12.3-py2.6.egg

grep Genshi /usr/lib/python2.6/site-packages/*.pth
grep Trac /usr/lib/python2.6/site-packages/*.pth

Possibilities are incorrect directory/file permissions such that
Apache cannot read .pth files or egg directories.

Corrupted .pth file such that Trac and Genshi not listed.

The eggs are zipped eggs and not expanded eggs and Python cannot
unpack the eggs at runtime because Python egg cache directory is not
writable, or already contains a corrupted version of the packages.

Read:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights_Of_Apache_User

Graham

Williams

unread,
Jul 14, 2012, 9:35:28 AM7/14/12
to mod...@googlegroups.com
Thanks Graham for pointing me in the right direction!

My solution was to remove the Genshi and Trac site-package eggs and reinstall them.  There must have been something corrupted.  With good eggs my script was able to access the trac.web.main modules.

Thanks a bunch!


Reply all
Reply to author
Forward
0 new messages