I can confirm this is true for mod_wsgi < 3.1 and mod_python < 3.3.1

As of mod_wsgi 3.1 and mod_python 3.3.1 they can coexist together

Unfortunately, according to EPEL policy, packages from EPEL cannot conflict with packages from RedHat.

I think you might be mis-interpretting the policy.  The way I read it is... the package can't conflict with anything in Redhat Base....  which mod_wsgi does do inherently... because the software itself produces a conflicting situation.  Currently, the package is missing an explicit Conflict... that doesn't mean it doesn't conflict, it means the mod_wsgi package is incomplete.  

That said, perhaps under the guidelines, it should have never been added (which I think wouldn't be right either, and doesn't fit the policy because mod_python is optional so maybe that should be brought up in the epel meeting).  That said... the package is there... I think it would be better for the user to explicitly conflict the packages rather than just letting them both be installed... and then having Apache segfault... a situation that now the user has to track down and resolve.

This ticket is not resolved IMO.  I see one of two resolutions:

a) Take it up with the EPEL community, maybe in the next irc meeting.  Perhaps we can modify the policy for edge cases like this.

b) Work with the RHEL maintainers to determine if mod_python can be upgraded to 3.3.1 in RHEL5 (not likely) or if they can backport changes that would allow mod_python to function next to mod_wsgi....   as well as do the same yourself for mod_wsgi.


I would say 'b' is just not feasible based on update guidelines for RHEL/EPEL...  so I would encourage 'a'.  Leaving it as-is is not the best situation for anyone.

I agree that I may be mis-interpreting the policy, as such I will pursue 'a'.  Additionally, I am working to get mod_wsgi updated to a compatible version in F-12+ in the hopes that RHEL considers it for inclusion in RHEL6 per bug 510323 [https://bugzilla.redhat.com/show_bug.cgi?id=510323].

I will bring it up on the mailing list today.

Why is mod_wsgi being penalised when the conflict isn't the fault of mod_wsgi but a problem with the mod_python package you have or the way that the Python package is built on RHEL?

The real problem is going to be due to mod_python and/or mod_wsgi being compiled against a Python installation which provides only a static Python library. That is, Python was never configured with --enable-shared or it was not ensured the Apache modules were linked against the shared library if it was.

The problem this causes is that a static copy of Python library is embodied within both Apache modules and when they are both loaded it causes symbol conflicts which result in odd things happening at run time including the behaviour you are likely seeing.

In other words, there is nothing wrong with mod_wsgi itself to be fixed, it is the way that packages are build on RHEL. The mod_wsgi documentation even highlights this specific problem with RedHat distributions.

The only other possibility is that you are supplying an absolutely ancient version of mod_python, ie., mod_python 2.7.10 or 3.1.4 released back in 2004 and 2005. It is known that those versions can't coexist with mod_wsgi because mod_python's handling of Python GIL is quite broken in those versions making it impossible for other modules relying on Python to coexist. It is believed that mod_wsgi should work with mod_python 3.2 through 3.3.1 with no problem, with 3.3.1 having being released back in 2007.

For the record, mod_wsgi was designed, with some significant thought, to be able to coexist with mod_python even though mod_python breaks various rules in respect of the use of Python in an embedded situation. Except for those really old versions of mod_python there should be no issue so long as Python shared libraries are used.

Maybe you should investigate which of these possibilities is the reason for the conflict instead of just assuming that mod_wsgi is the problem.

(In reply to comment #5)
> Why is mod_wsgi being penalised when the conflict isn't the fault of mod_wsgi
> but a problem with the mod_python package you have or the way that the Python
> package is built on RHEL?
> 
mod_wsgi is not being penalised, by policy EPEL packages should not conflict with Red Hat packages therefore mod_wsgi (from EPEL) should not conflict with mod_python (from Red Hat).

> The real problem is going to be due to mod_python and/or mod_wsgi being
> compiled against a Python installation which provides only a static Python
> library. That is, Python was never configured with --enable-shared or it was
> not ensured the Apache modules were linked against the shared library if it
> was.
Agreed.
> 
> The problem this causes is that a static copy of Python library is embodied
> within both Apache modules and when they are both loaded it causes symbol
> conflicts which result in odd things happening at run time including the
> behaviour you are likely seeing.
> 
> In other words, there is nothing wrong with mod_wsgi itself to be fixed, it is
> the way that packages are build on RHEL. The mod_wsgi documentation even
> highlights this specific problem with RedHat distributions.
> 
> The only other possibility is that you are supplying an absolutely ancient
> version of mod_python, ie., mod_python 2.7.10 or 3.1.4 released back in 2004
> and 2005. It is known that those versions can't coexist with mod_wsgi because
> mod_python's handling of Python GIL is quite broken in those versions making it
> impossible for other modules relying on Python to coexist. It is believed that
> mod_wsgi should work with mod_python 3.2 through 3.3.1 with no problem, with
> 3.3.1 having being released back in 2007.
The version shipped with RHEL5 is 3.2.8.  From testing, mod_wsgi 3.1 and mod_python 3.2.8 do not work together, there is no segfault but mod_python throws errors:

[Tue Mar 09 08:14:08 2010] [error] [client 127.0.0.1] PythonHandler test: Traceback (most recent call last):
[Tue Mar 09 08:14:08 2010] [error] [client 127.0.0.1] PythonHandler test:   File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 291, in HandlerDispatch\n    arg=req, silent=hlist.silent)
[Tue Mar 09 08:14:08 2010] [error] [client 127.0.0.1] PythonHandler test:   File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 531, in resolve_object\n    raise AttributeError, s
[Tue Mar 09 08:14:08 2010] [error] [client 127.0.0.1] PythonHandler test: AttributeError: module '/usr/lib64/python2.4/test/__init__.pyc' contains no 'handler'

> 
> For the record, mod_wsgi was designed, with some significant thought, to be
> able to coexist with mod_python even though mod_python breaks various rules in
> respect of the use of Python in an embedded situation. Except for those really
> old versions of mod_python there should be no issue so long as Python shared
> libraries are used.
> 
I don't think anyone is blaming mod_wsgi, it just happens to be that only mod_wsgi can change, not mod_python.

The error:

PythonHandler test: AttributeError: module '/usr/lib64/python2.4/test/__init__.pyc' contains no 'handler'

is purely because you made the mistake of calling your test script file 'test.py' instead of something else. That Python module name is effectively reserved as it is a standard module in the Python distribution and the order of module search paths as set up by mod_python can result in precedence being given to the Python modules over mod_python script files. I am still surprised you would even get that message though as nothing mod_wsgi does should itself cause that and it could happen all by itself if using mod_python.

If you change 'test.py' to 'mptest.py' you may well find that you get past that problem.

I still don't have confidence in 3.2.X releases of mod_python working at same time as mod_wsgi for other reasons, but that traceback is not a problem with mod_python and/or mod_wsgi but more likely the test setup. It doesn't present as a problem in mod_python 3.3.1 because how module search paths were implemented was changed quite a lot to avoid problems similar to this.

A quite long description of all the module importing bugs in 3.2.X can be found in:

http://www.dscpl.com.au/wiki/ModPython/Articles/ModuleImportingIsBroken

In respect of being penalised, was thinking more in terms of it being suggested by the 'conflict' label that mod_wsgi was in some way broken. So is a perception issue. I agree I am getting a bit over sensitive to such perception issues at the moment as there seems to be ongoing stream of people pointing at mod_wsgi saying it is broken for one reason of another where it never turns out to be the case.

(In reply to comment #7)
> <snip>
> If you change 'test.py' to 'mptest.py' you may well find that you get past that
> problem.
> 
Thanks for that, you are correct, renaming it did fix it.


> I still don't have confidence in 3.2.X releases of mod_python working at same
> time as mod_wsgi for other reasons, but that traceback is not a problem with
> mod_python and/or mod_wsgi but more likely the test setup. It doesn't present
> as a problem in mod_python 3.3.1 because how module search paths were
> implemented was changed quite a lot to avoid problems similar to this.
> 

Do you have a set of tests cases I could try?  That way I can confirm whether or not they are still conflicting.  Fixing the name issue does allow me to run both mod_wsgi and mod_python at the same time, using my simple test cases.

Thanks

If it works then it may well work overall. If there was a problem I would expect to have seen deadlocks pretty quickly.

I guess the danger case to check is to configure mod_wsgi daemon mode and run a WSGI test script under that. If the problem exists that I am concerned about then the mod_wsgi daemon process will deadlock on startup, or less likely when a WSGI script running in that daemon process is triggered by a request.

It is quite possible that although very early mod_wsgi versions wouldn't work with mod_python 3.2.X, that further tweaks I made to mod_wsgi initialisation in daemon process to further accommodate the broken nature of mod_python saw it then being able to work with mod_python 3.2.X.

Emphasising the point again, as far as I know any conflict would only exist when trying to use mod_wsgi daemon mode when mod_python also loaded at the same time. There likely would be no problem if running a WSGI script under mod_wsgi embedded mode.

mod_wsgi-3.2-1.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/mod_wsgi-3.2-1.el5

mod_wsgi-3.2-1.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mod_wsgi'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/mod_wsgi-3.2-1.el5

mod_wsgi-3.2-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.