Hi Graham,

Thanks for the quick response.

Hopefully some of this information will help pinpoint the problem.



1.

When we built Python, we did not set a --prefix, but did only:
$ ./configure --enable-shared
$ make
$ sudo make install

The installation seemed to put files into various places that 
weren't being seen by other programs until we ran:
$ sudo ln -s /usr/local/lib/libpython2.6.so.1.0 /usr/lib64/libpython2.6.so.1.0
$ sudo ln -s /usr/local/bin/python2.6 /usr/bin/python2.6

Python 2.4 is still also running fine on this system
(as seems to be needed for yum, and possibly other CentOS tools, etc.)



2.

The WSGI test app shows what it thinks sys.version is:

Hello World (Test WSGI)! from Python sys.version=
2.6.5 (r265:79063, Apr  7 2010, 21:10:55) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]

... as expected.



3. 

Here is more information you (Graham) asked for about apache + mod_wsgi:

Apache is being run by standard system init:
$ sudo /sbin/chkconfig httpd on
$ sudo /sbin/service httpd start


Here is the mod_wsgi ldd dump:
$ ldd /usr/lib64/httpd/modules/mod_wsgi.so 
        libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 
(0x00002b61a541b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b61a57ca000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b61a59e5000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00002b61a5bea000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b61a5ded000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b61a6070000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037eaa00000)



Here is our mod_wsgi related httpd.conf configuration:

    LoadModule wsgi_module modules/mod_wsgi.so
    WSGISocketPrefix /var/run/wsgi

and from within our VirtualHost:

    WSGIDaemonProcess myapp processes=10 threads=1 display-name=%{GROUP}
    WSGIProcessGroup myapp
    WSGIScriptAlias / /home/myapp/wsgi/test.wsgi

Note that we already disabled mod_python (and many other unused modules).


For completeness,
$ uname -a
Linux host.domain.com 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 
x86_64 x86_64 x86_64 GNU/Linux





4.

This comment appears in threading.py's Thread.__delete method concerning
KeyErrors.  I have no idea what it means or if it's even relevant:

def __delete(self):
    "Remove current thread from the dict of currently running threads."

    # Notes about running with dummy_thread:
    #
    # Must take care to not raise an exception if dummy_thread is being
    # used (and thus this module is being used as an instance of
    # dummy_threading).  dummy_thread.get_ident() always returns -1 since
    # there is only one thread if dummy_thread is being used.  Thus
    # len(_active) is always <= 1 here, and any Thread instance created
    # overwrites the (if any) thread currently registered in _active.
    #
    # An instance of _MainThread is always created by 'threading'.  This
    # gets overwritten the instant an instance of Thread is created; both
    # threads return -1 from dummy_thread.get_ident() and thus have the
    # same key in the dict.  So when the _MainThread instance created by
    # 'threading' tries to clean itself up when atexit calls this method
    # it gets a KeyError if another Thread instance was created.
    #
    # This all means that KeyError from trying to delete something from
    # _active if dummy_threading is being used is a red herring.  But
    # since it isn't if dummy_threading is *not* being used then don't
    # hide the exception.



So anyway, to reiterate the situation, web apps seem to work...
They just keeps logging these threading KeyErrors in error_log,
 even when we strip the installation down the to minimum wsgi app:

[Fri Apr 09 04:34:54 2010] [error] Exception KeyError:
KeyError(47125770724704,) in <module 'threading' from '/usr/local/lib/
python2.6/threading.pyc'> ignored
[Fri Apr 09 04:34:54 2010] [error] Exception KeyError:
KeyError(47125770724704,) in <module 'threading' from '/usr/local/lib/
python2.6/threading.pyc'> ignored
...

Thank you again.

-- 
dk



On Apr 8, 2010, at 10:04 PM, Graham Dumpleton wrote:

> Provide all the mod_wsgi related configuration from Apache configuration 
> files.
> 
> Provide output of running:
> 
>  ldd mod_wsgi.so
> 
> on mod_wsgi.so module file where ever it is installed.
> 
> Indicate whether Apache is being run as you or out of standard root
> init startup. If as you, supply result of doing:
> 
>  env | grep PYTHON
> 
> Graham

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/modwsgi?hl=en.

Reply via email to