Python version mismatch, expected '2.7.2+', found '2.7.3'

Bug #1073147 reported by guigao on 2012-10-30
92
This bug affects 20 people
Affects Status Importance Assigned to Milestone
libapache2-mod-python (Ubuntu)
High
Unassigned

Bug Description

Running Ubuntu 12.04 server 32 bits.
Installed Apache2 and libapache2-mod-o´python through apt-get.
I'm getting the following error:

[Tue Oct 30 02:11:00 2012] [notice] caught SIGTERM, shutting down
[Tue Oct 30 02:11:00 2012] [error] python_init: Python version mismatch, expected '2.7.2+', found '2.7.3'.
[Tue Oct 30 02:11:00 2012] [error] python_init: Python executable found '/usr/bin/python'.
[Tue Oct 30 02:11:00 2012] [error] python_init: Python path being used '/usr/lib/python2.7/:/usr/lib/python2.7/plat-linux2:/usr/lib/python2.7/lib-tk:/usr/lib/python2.7/lib-old:/usr/lib/python2.7/lib-dynload'.
[Tue Oct 30 02:11:00 2012] [notice] mod_python: Creating 8 session mutexes based on 6 max processes and 25 max threads.
[Tue Oct 30 02:11:00 2012] [notice] mod_python: using mutex_directory /tmp
[Tue Oct 30 02:11:00 2012] [notice] Apache/2.2.22 (Ubuntu) mod_python/3.3.1 Python/2.7.3 configured -- resuming normal operations

Matthias Klose (doko) wrote :

known issue, however it's a warning, the module continues to work.

Changed in libapache2-mod-python (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
guigao (guilherme-fernandes) wrote :

The error log says ERROR and I wasn't able to make it work.

[Tue Oct 30 02:11:00 2012] *[error]* python_init: Python version mismatch, expected '2.7.2+', found '2.7.3'.

Latter I installed libapache2-mod-wsgi and got the same type of message, but now just as a warning.

So, with libapache2-mod-wsgi I got a warning and the module continues to work. But with libapache2-mod-python I got an ERROR and the module doesn't work.

So I still think it is an error that should be fixed. Especially because it has a very simple solution: just recompile with python 2.7.3.

Thanks

rob cain (rcain-3) wrote :

Could I add to this please - o too have experienced this exact problem on apache restart - whilst/after adding ssl directives to my vhosts entries - i was forced to revert out ssl entries to get apache+vhosts to start again. i made the vhosts entries using zpanal apache vhosts overrides, but also made manual mods, same result - doesnt loke running/staring ssl for vhosts, because of the python mismatch.

this seems like a really serious build error somewhere to me

 - the build dependency shown by the apache error is:

`[Sun Dec 09 02:15:03 2012] [error] python_init: Python version mismatch, expected '2.7.2+', found '2.7.3'.`

 - wheras the version shows:

`root@server88-208-201-24:~# apt-get install libapache2-mod-python
Reading package lists... Done
Building dependency tree
Reading state information... Done
libapache2-mod-python is already the newest version.`

 - this is preventing me using SSL at present, and is becomming increasingly well documented:

 - vis: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python/+bug/1073147
 - vis: http://forums.zpanelcp.com/showthread.php?7442-Is-ZPX-changing-the-VHOSTS-after-eacht-daemon-run&p=59642&viewfull=1#post59642
 - vis: http://library.linode.com/web-servers/apache/installation/ubuntu-12.04-precise-pangolin
 - vis: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python
 - vis: http://ubuntuforums.org/showthread.php?t=2088282

could we much this up the priority stack please?

any work rounds, solutions even?

(ps. i'll be adding this to the forums also in the hope someone has already cracked it without a complete local rebuild of apache2, which is a headache i could well do without.

thanks

TJ (tj) wrote :

After a do-release-upgrade from 10.04.1 to 12.04.1 I'm seeing this issue too. It causes various HTTP vhosts that use Python applications (in this case Trac) to report:

500 Internal Server Error

This is a serious regression affecting production servers. I've increased the bug importance accordingly.

The server's central /var/log/apache2/error.log reports:

[Fri Jan 18 16:14:49 2013] [notice] SIGHUP received. Attempting to restart
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[Fri Jan 18 16:14:54 2013] [error] python_init: Python version mismatch, expected '2.7.2+', found '2.7.3'.
[Fri Jan 18 16:14:54 2013] [error] python_init: Python executable found '/usr/bin/python'.
[Fri Jan 18 16:14:54 2013] [error] python_init: Python path being used '/usr/lib/python2.7/:/usr/lib/python2.7/plat-linux2:/usr/lib/python2.7/lib-tk:/usr/lib/python2.7/lib-old:/usr/lib/python2.7/lib-dynload'.
[Fri Jan 18 16:14:54 2013] [notice] mod_python: Creating 8 session mutexes based on 4 max processes and 25 max threads.
[Fri Jan 18 16:14:54 2013] [notice] mod_python: using mutex_directory /tmp
[Fri Jan 18 16:14:54 2013] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Fri Jan 18 16:14:54 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+.
[Fri Jan 18 16:14:54 2013] [warn] mod_wsgi: Runtime using Python/2.7.3.
[Fri Jan 18 16:14:55 2013] [notice] Apache/2.2.22 (Ubuntu) DAV/2 mod_fcgid/2.3.6 proxy_html/3.0.1 mod_python/3.3.1 Python/2.7.3 mod_ssl/2.2.22 OpenSSL/1.0.1 mod_wsgi/3.3 mod_perl/2.0.5 Perl/v5.14.2 configured -- resuming normal operations

Changed in libapache2-mod-python (Ubuntu):
importance: Low → High
TJ (tj) wrote :

Looking at the build history the problem seems to be that the package was last built for Oneiric which defaults to using Python 2.7.2 (on the build server).

There was no rebuild for Precise which uses Python 2.7.3 as the default. Therefore the Precise package is the same one built for Oneiric - it expects to be running on Python 2.7.2.

The latest change (revision 16) to use dh_python2 in the package's "debian/rules" uses the flag "--no-guessing-versions" which appears to cause the build system to ignore some multi-version support:

dh_python2 -plibapache2-mod-python --no-guessing-versions

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/libapache2-mod-python/precise/revision/16

This build server Python version being older than the runtime seems to be the cause of the similar warning for mod_wsgi (build system using the older Python 2.7.2).

TJ (tj) on 2013-01-19
no longer affects: mod-python
Alan Frye (alfrye) wrote :

I upgrade to 12.04 yesterday and noticed that none of my python sites are working. I am getting this same error. Is there a fix or a work around for this issue.

Robie Basak (racb) wrote :

I can't reproduce this on 12.04, using package versions:

apache2 2.2.22-1ubuntu1.2
libapache2-mod-python 3.3.1-9ubuntu1

A basic "hello world" python page works correctly for me.

Please can someone affected post a minimal test case? We can't update a stable release without a test case. Thanks!

Robert Hernandez (0-robert) wrote :

# You have to recompile mod-python and/or mod-wsgi.

# Remove mods
apt-get remove libapache2-mod-python libapache2-mod-wsgi

# Get dependencies
apt-get build-dep libapache2-mod-python libapache2-mod-wsgi

# Build mod-python
mkdir /tmp/python
cd /tmp/python
apt-get source libapache2-mod-python
cd libapache2-mod-python-[x.x.x]
dpkg-buildpackage -rfakeroot -b

#Build mod-wsgi
mkdir /tmp/wsgi
cd /tmp/wsgi
apt-get source libapache2-mod-wsgi
cd mod-wsgi-[x.x.x]
dpkg-buildpackage -rfakeroot -b

# Install newly compiled packages
dpkg -i /tmp/python/libapache2-mod-python-[x.x].deb /tmp/wsgi/libapache2-mod-wsgi-[x.x].deb

Jason Cline (jcline) wrote :

Recompiling mod-pythong and mod-wsgi did indeed produce fewer warnings, however I'm still seeing 500 errors. Did the work around work for anyone else?

Kinney (tokyo-kinney) wrote :

The re-compile by Robert also requires you to enable the module with apache2 at the end.

# a2enmod wsgi
# service apache2 restart
# ls -lah /etc/apache2/mods-enabled/
lrwxrwxrwx 1 root root 27 Oct 9 02:57 wsgi.conf -> ../mods-available/wsgi.conf
lrwxrwxrwx 1 root root 27 Oct 9 02:57 wsgi.load -> ../mods-available/wsgi.load

Note: Done on Ubuntu 12.04.5

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.