[mod_python] Fwd: mod python configuration problem

Graham Dumpleton grahamd at dscpl.com.au
Wed Jul 13 18:55:34 EDT 2005

On 14/07/2005, at 4:11 AM, Alexandre F. Santos wrote:
> Mod_python shows up in the apache configuration (as seen by 
> phpinfo()). I
> asked the admin to do the test recommended in the tutorial to identify
> mod_python and send me the output:
> -------------------
> # python
> Python 2.3.5 (#2, May  4 2005, 08:51:39)
> [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import mod_python.psp
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.3/site-packages/mod_python/psp.py", line 20, 
> in ?
>     import apache, Session, util, _psp
>   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 
> 28, in
> ?
>     import _apache
> ImportError: No module named _apache
> -------------------
> So mod_python 3.1.3 seems indeed to be installed and working.

That only shows that the part of mod_python which lives outside of 
has been installed. To know for sure that the Apache DSO module for
mod_python has been installed, you need to sight the startup line in
Apache log file for it. Ie., something like:

   [Tue Feb 01 16:08:21 2005] [notice] Apache/2.0.51 (Unix)
     mod_python/3.1.3 Python/2.3 configured -- resuming normal operations

> I created a home/xp/ folder where I put a hello.txt file and verifyed 
> that I
> could access it via the web.
> I then created there an .htaccess file:
> AddHandler python-program .py
> PythonHandler mptest
> PythonDebug On
> and a mptest.py file:
>> from mod_python import apache
> def handler(req):
>     req.content_type = 'text/plain'
>     req.send_http_header()
>     req.write('mptest.py\n')
>     return apache.OK
> Going for the /xp/mptest.py file with my browser yielded the following:
> -------------------------
> Internal Server Error

After having added in the .htaccess file, could you still access the 
file or did attempting to access it also yield an internal server error.

If accessing "hello.txt" also yielded an internal server error, it 
could be
options in the .htaccess file. I know the article says:

   If instead of the string "mptest.py" you see the actual source code 
   in the file, or your browser asks you to save the response to a file 
and that
   file contains the source code, the main Apache configuration may not 
be enabled
   so as to allow you to specify Apache handlers in a ".htaccess" file. 
To enable
   this facility, edit your main Apache configuration file and add in an
   appropriate location:

     <Directory /some/directory>
     AllowOverride FileInfo

but it may be possible that the lack of the AllowOverride for FileInfo 
also perhaps result in an internal server error response. If this is 
the case,
accessing "hello.txt" should yield the error as well and you'll need to 
the AllowOverride option enabled for your directory.

> Now of course I don't have access to the server error log, but before I
> contact the admin, could you give me some indications about what could 
> be
> wrong and what would be the best approach to address this issue?

Since you have PythonDebug set to On, if mod_python was working and it 
was a
problem in your handler, or ability to find the handler, you would have 
a stack trace back in the browser instead of the generic 500 error, so 
likely a problem there.

Unfortunately this leaves a horrid set of possibilities where even what 
is in
the Apache error log may not help. This is because for certain 500 
internal to mod_python when trying to initially process your request, it
either doesn't log anything at all, or logs it to stderr but doesn't 
it properly meaning that it doesn't appear in the Apache logs until 
Apache is
next shutdown/restarted. Both these cases have been dealt with for the 
version of mod_python, but you are going to have to contend with them.


The cause of these problems tends to be where for some reason the 
version of
the mod_python module loaded into Apache is looking in the wrong place 
the Python code files installed into the site-packages directory of the
Python installation, ie., those which the command line test at start was
trying to determine existed. It could simply not be finding the Python 
files or finding the wrong version if there are multiple versions of 
installed on the system.

All I can suggest is getting proof from the logs that mod_python is 
Ie., that the line above exists in some form. Get any errors messages 
look like that they may be from mod_python in the log from the time when
the request was made, or any other strange errors that might have 
in the log when Apache was next shutdown/restarted.


More information about the Mod_python mailing list