search

Copterfly / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

Some libraries may be unusable when used by both mod_wsgi and at least one other other apache module (such as PHP) #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Some libraries are unusable when run by mod_wsgi and another apache module
at the same time and they expects different versions. A prominent example
is the mysql client library used by both the MySQL-python module and the
PHP module in apache. Misleading, unusable tracebacks are produced to the
apache error logs.

A post at the mod_python FAQ describes this weird issue:
http://www.modpython.org/FAQ/faqw.py?req=all#2.13

It is somehow complex to reproduce:

1. Install a Debian Sarge server with Apache2 and PHP (4 or 5), ensure that
mysql is enabled in PHP and the client libraries are included in your
distribution.

2. Install mod_wsgi 1.0, other versions could behave the same way, since it
seems to be an apache library issue.

3. Write a WSGI app using mysql through MySQL-python-1.2.2. By using
SQLObject you can make this very fast. Creating a table object such as
below would cause the error without doing anything with the DB:

__connection__='mysql://someuser:passwd:localhost/somedb'
class SomeTable:
    class sqlmeta:
        fromDatabase=True

The script will run fine from the command line with the same version of
python, but won't run when called from the apache process (when you try to
see it's output in the browser).

You will get unusable, partial tracebacks and 500 Internal server error
responses. Usually it takes hours for an experienced programmer to catch
the real cause of this kind of bug, which is really dangerous thing in an
enterprise environment.

I'm not sure that it can be fixed in mod_wsgi or mod_python, since this
could be caused by the library handling of apache or Linux. The bug can be
produced by various other libraries such as expat or libpng when used by
both mod_wsgi and the php module.

OS: Linux, Debian Sarge 3.1, up to date (but not the current stable anymore)
Python 2.5.1, compiled from official sources
mod_wsgi 1.0 (compiled on 13th April 2007 as a recent version)
MySQL-python-1.2.2
SQLObject 0.9.1 (not essential, but convenient to reproduce the bug)
mysql  Ver 14.7 Distrib 4.1.11
mysqld  Ver 4.1.11-Debian_4sarge7
Apache/2.0.54 MPM prefork
PHP 4.3.10-19 (cli) (built: Mar  5 2007 20:46:29)
Zend Engine v1.3.0

Typical apache error log lines:

[Sun Aug 26 00:30:05 2007] [notice] [client <IP>] mod_wsgi (pid=20824):
Target WSGI script '/var/www/ourhost.hu/ds/datasource.py' cannot be loaded
as Python module.
[Sun Aug 26 00:30:05 2007] [notice] [client <IP>] mod_wsgi (pid=20824):
Exception occurred within WSGI script '/var/www/ourhost.hu/ds/datasource.py'.
[Sun Aug 26 00:30:05 2007] [error] [client <IP>] Traceback (most recent
call last):
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]   File
"/var/www/ourhost.hu/ds/datasource.py", line 6, in <module>
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]     from befi import *
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]   File
"/var/www/ourhost.hu/ds/befi.py", line 6, in <module>
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]     from config_db import *
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]   File
"/var/www/ourhost.hu/ds/config_db.py", line 7, in <module>
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]     class Alap(SO.SQLObject):
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]   File
"/usr/local/lib/python2.5/site-packages/SQLObject-0.9.1-py2.5.egg/sqlobject/decl
arative.py",
line 121, in __new__
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]     cls.__classinit__(cls,
new_attrs)
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]   File
"/usr/local/lib/python2.5/site-packages/SQLObject-0.9.1-py2.5.egg/sqlobject/main
.py",
line 792, in __classinit__
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]    
cls.sqlmeta.addColumnsFromDatabase()
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]   File
"/usr/local/lib/python2.5/site-packages/SQLObject-0.9.1-py2.5.egg/sqlobject/main
.py",
line 450, in addColumnsFromDatabase
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]     for columnDef in
conn.columnsFromSchema(sqlmeta.table, soClass):
[Sun Aug 26 00:30:05 2007] [error] [client <IP>]   File
"/usr/local/lib/python2.5/site-packages/SQLObject-0.9.1-py2.5.egg/sqlobject/mysq
l/mysqlconnection.py",
line 212, in columnsFromSchema

Note, that no real exception info is produced, only an unusable traceback.
This points to the line of code where the python script first tries to use
the mysql library, usually something related to an SQL cursor. But this is
irrelevant and can be anything in that library, since a wrong version is
used not the one expected by python.

Original issue reported on code.google.com by ferenczi.viktor on 25 Aug 2007 at 11:33

GoogleCodeExporter commented 9 years ago 
This issue is described in the section 'MySQL Shared Library Conflicts' of
http://code.google.com/p/modwsgi/wiki/ApplicationIssues document.

There are also sections in there describing similar things that can happen when 
using
SSL, expat, PHP md5hash and pysqlite.

Can you indicate if you were using daemon mode of mod_wsgi? Ie., using
WSGIDaemonProcess/WSGIProcessGroup to delegate WSGI application to run in a 
distinct
daemon process.

If PHP delays its loading of modules until Apache child process are created and
initialised, it is possible that using mod_wsgi daemon mode would result in the 
PHP
MySQL version mismatch not being a problem as the MySQL library required by PHP
wouldn't have been loaded in the mod_wsgi daemon process. I am not sure how PHP 
works
though so do not know if this will be the case or not. If PHP preloads 
everything in
Apache parent process, same problem would occur.

Use of daemon mode will not help in the case though where MySQL is being used 
by an
Apache module such as mod_auth_mysql or mod_dbd_mysql as in that case the MySQL
library which clashes would have definitely been loaded in the Apache parent. 
For
this situation, you would get similar problems with PHP if it used a different
version of the MySQL library. Thus doesn't apply only to mod_python and 
mod_wsgi and
can cause problems for PHP as well.

Original comment by Graham.Dumpleton@gmail.com on 26 Aug 2007 at 1:28

GoogleCodeExporter commented 9 years ago

Original comment by Graham.Dumpleton@gmail.com on 31 Aug 2007 at 12:45