mod_wsgi.so-3.2 gives errors

[Tobias Bradtke]

When mod_wsgi.so links to mod_wsgi.so-3.2, apache2 throws error messages:

# ls /usr/lib/apache2/modules/mod_wsgi.so* -l
lrwxrwxrwx 1 root root 40 2011-04-13 17:45 /usr/lib/apache2/modules/mod_wsgi.so -> /usr/lib/apache2/modules/mod_wsgi.so-3.2
-rw-r--r-- 1 root root 156320 2011-04-07 14:10 /usr/lib/apache2/modules/mod_wsgi.so-3.1
-rw-r--r-- 1 root root 156320 2011-04-07 14:10 /usr/lib/apache2/modules/mod_wsgi.so-3.2

# tail -f /var/log/apache2/error.log
[Wed Apr 13 17:45:05 2011] [notice] Apache/2.2.17 (Ubuntu) mod_wsgi/3.3 Python/3.2 configured -- resuming normal operations
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
[Wed Apr 13 17:45:07 2011] [notice] child pid 6114 exit signal Aborted (6)
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
[Wed Apr 13 17:45:09 2011] [notice] child pid 6257 exit signal Aborted (6)
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
[Wed Apr 13 17:45:11 2011] [notice] child pid 6321 exit signal Aborted (6)
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
[Wed Apr 13 17:45:13 2011] [notice] child pid 6355 exit signal Aborted (6)
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
[Wed Apr 13 17:45:15 2011] [notice] child pid 6432 exit signal Aborted (6)
...

Linking to mod_wsgi.so-3.1 fixes this for me.

# cp -sf /usr/lib/apache2/modules/mod_wsgi.so{-3.1,}

# ls /usr/lib/apache2/modules/mod_wsgi.so* -l
lrwxrwxrwx 1 root root 40 2011-04-13 17:50 /usr/lib/apache2/modules/mod_wsgi.so -> /usr/lib/apache2/modules/mod_wsgi.so-3.1
-rw-r--r-- 1 root root 156320 2011-04-07 14:10 /usr/lib/apache2/modules/mod_wsgi.so-3.1
-rw-r--r-- 1 root root 156320 2011-04-07 14:10 /usr/lib/apache2/modules/mod_wsgi.so-3.2

# service apache2 restart

# tail -f /var/log/apache2/error.log
[Wed Apr 13 17:50:42 2011] [notice] Apache/2.2.17 (Ubuntu) mod_wsgi/3.3 Python/3.1.3 configured -- resuming normal operations

[James Page (james-page)]

Confirm on up-to-date Natty amd64:

Fatal Python error: PyEval_AcquireLock: current thread state is NULL
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
[Fri Apr 15 15:29:21 2011] [notice] Apache/2.2.17 (Ubuntu) mod_wsgi/3.3 Python/3.2 configured -- resuming normal operations
[Fri Apr 15 15:29:21 2011] [notice] child pid 4480 exit signal Aborted (6)
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
[Fri Apr 15 15:29:22 2011] [notice] child pid 4479 exit signal Aborted (6)
[Fri Apr 15 15:29:35 2011] [notice] SIGUSR1 received. Doing graceful restart
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
[Fri Apr 15 15:29:35 2011] [notice] Apache/2.2.17 (Ubuntu) mod_wsgi/3.3 Python/3.2 configured -- resuming normal operations
[Fri Apr 15 15:29:35 2011] [notice] child pid 4560 exit signal Aborted (6)
Fatal Python error: PyEval_AcquireLock: current thread state is NULL
[Fri Apr 15 15:29:36 2011] [notice] child pid 4590 exit signal Aborted (6)

[Barry Warsaw (barry)]

<barry> jamespage: http://docs.python.org/dev/whatsnew/3.2.html [11:48]
<barry> "The misleading functions PyEval_AcquireLock() and
        PyEval_ReleaseLock() have been officially deprecated. The thread-state
        aware APIs (such as PyEval_SaveThread() and PyEval_RestoreThread())
        should be used instead."
<barry> i see PyEval_AcquireLock in the error logs so perhaps mod_wsgi is
        using those api's incorrectly [11:49]
<jamespage> barry: upstream trunk has removed all but one call to
            PyEval_AcquireLock() so I guess its something todo with that.
<barry> jamespage: yep, highly likely
<barry> jamespage: i guess mod_wsgi totally unusable in natty w/py3.2?
<jamespage> barry: yep - even "Hello World" would not work
<jamespage> barry: my feel would be to remove the python3.2 built version of
            the module for natty; and sync up again next release when upstream
            officially support. [11:51]
<barry> jamespage: seems reasonable. i wonder if doko or ScottK can chime in
<barry> jamespage: and we can always build the new version in a ppa for natty
<ScottK> barry: I think POX and bzed would be the ones to hear from. [11:53]
<ScottK> (since they are the mod-wsgi maintainers)

The upshot is that mod-wsgi won't work for Python 3.2 in natty. Is it worth removing the 3.2 build for natty?

[Graham Dumpleton (graham-dumpleton)]

Patch from mod_wsgi 4.0 has been back port to mod_wsgi 3.X and can be obtained from:

http://code.google.com/p/modwsgi/source/detail?r=8633d5afeea845a12c028cfae31dc828c5ce8908

Patch has also been sent to Bernd and Piotr.

[Graham Dumpleton (graham-dumpleton)]

Okay, you can view the differences, but seems GoogleCode site doesn't make it easy to download a patch file for differences. So, have attached patch here as well. The patch is against mod_wsgi 3.3, but should still apply properly to mod_wsgi 3.2.

Recommended that this only be applied when building for Python 3.2 as not sure if changes will in Python 2.X prevent mod_python from being used at same time as mod_python's use of threading APIs broken and have worked around that in the past. Now that mod_wsgi does things by the book, there may be issues.

[James Page (james-page)]

Thanks Graham

I'll update the package with the supplied patch and propose a merge for natty today.

[Launchpad Janitor (janitor)]

This bug was fixed in the package mod-wsgi - 3.3-2ubuntu2

---------------
mod-wsgi (3.3-2ubuntu2) natty; urgency=low

  * Full python >= 3.2 support (LP: #759943):
    - debian/patches/fix-python-3.2-lp-749720.patch: removed -
      superceded by python-3.2-compat.patch.
    - debian/patches/python-3.2-compat.patch: full patch to support
      python >= 3.2 from Graham Dumpleton.
 -- James Page <email address hidden> Tue, 19 Apr 2011 08:22:47 +0100