In a harrowing attempt to get mod_wsgi to run on CentOS 5.4, I've added Python 2.6 as an optional library following the instructions here. The configuration seems fine except that when trying to ping the server the Apache log prints this error:
mod_wsgi (pid=20033, process='otalo', application='127.0.0.1|'): Loading WSGI script '...django.wsgi'.
[Sat Mar 27 16:11:45 2010] [error] [client 171.66.52.218] mod_wsgi (pid=20033): Target WSGI script '...django.wsgi' cannot be loaded as Python module.
[Sat Mar 27 16:11:45 2010] [error] [client 171.66.52.218] mod_wsgi (pid=20033): Exception occurred processing WSGI script '...django.wsgi'.
[Sat Mar 27 16:11:45 2010] [error] [client 171.66.52.218] Traceback (most recent call last):
[Sat Mar 27 16:11:45 2010] [error] [client 171.66.52.218] File "...django.wsgi", line 8, in <module>
[Sat Mar 27 16:11:45 2010] [error] [client 171.66.52.218] import django.core.handlers.wsgi
[Sat Mar 27 16:11:45 2010] [error] [client 171.66.52.218] ImportError: No module named django.core.handlers.wsgi
when I go to my python2.6 install's command line and try 'import Django', the module is not found (ImportError). However, my default Python 2.4 installation (still working fine) is able to import successfully. How do I point Python 2.6 to Django?
You need to install Django specifically with/for the Python version that's meant to use it -- installs for 2.4 and 2.6 are always going to be separate (they have to be -- there are incompatibilities in binary and bytecode formats!). I don't know what, if any, possibilities CentOS offers for that -- I'd get Django's sources and install from sources (which boils down to: download, tar, cd, and finally a simple sudo python2.6 setup.py install -- or however else you run your 2.6 install of Python). Being a much better developer than I'm a system administrator, I always have a bias in favor of installing from sources for stuff that's really at the core of what I'm doing (especially Python versions and extensions).
I created a write up link text of my experiences of getting Django working on Redhat and and CentOS. I upgraded the version of python that I was using and started with init.d scripts.
Related
So I was trying to run my flask app in a virtualenv. But when trying to import mariadb which uses a .so file for the module I got this error:
File "(pathToEnv)/FlaskEnv/lib/python3.10/site- packages/mariadb/__init__.py", line 10$
[Mon Mar 21 14:52:43.074678 2022] [wsgi:error] [pid 27865] [client 192.168.1.128:42536] from ._mariadb import (
[Mon Mar 21 14:52:43.074723 2022] [wsgi:error] [pid 27865] [client 192.168.1.128:42536] ModuleNotFoundError: No module named 'mariadb._mariadb'
The same error happens for xxhash which also uses a .so file (possible correlation?) Every other module works fine under flask and when using either mariadb or xxhash in a normal python script they import fine.
Also notable is that this only started after I put Flask into a virtualenv. Before I had it run of the system wide ptyhon3.7 and now virtalenv python 3.10. I'm really puzzled what could be the cause of this, because it works fine in normal python scripts, but not on flask under apache
I had mod_wsgi working fine on RHEL/Apache2.4/python3.4/Django1.11/virtualenv. Then, I used pip within the virtualenv to upgrade numpy from 1.14.0 to 1.14.2, install pandas, and install a couple other modules. Then I restarted Apache and started getting server errors indicating AttributeError: 'module' object has no attribute 'arange' when trying to call numpy.arange, or similar errors when trying to call matplotlib.use('Agg'), etc.
I replaced wsgi.py with the following and it works fine. As soon as I uncomment any of the numpy or matplotlib calls it returns a 500 error and in the apache error log it shows an error similar to AttributeError: 'module' object has no attribute ...
import datetime
import sys
import numpy as np
import matplotlib as mpl
import mod_wsgi
def application(env, start_response):
#mpl.use('Agg')
#a = np.arange(15).reshape(3, 5)
#a = np.array([2,3,4])
status = '200 OK'
output = 'Hello World! This is the wsgi app generated from python!'
output += '\n\ncurrent time is: '+str(datetime.datetime.now())
output += '\n\nsys.executable='+sys.executable
output += '\n\nsys.path='+str(sys.path)
output += '\n\nsys.version=' + str(sys.version)
output += '\n\nsys.prefix=' + str(sys.prefix)
output += '\n\nmod_wsgi.version='+str(mod_wsgi.version)
output += '\n\n\nEnvironment Variables:\n\n'+'\n'.join('%s: %s' % (k, v) for (k, v) in env.items())
output = bytes(output,'utf-8')
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
Relevant output from this wsgi.py:
sys.executable=/usr/bin/python3
sys.path=['/usr/local/virtualenvs/myapp/wsgiapp', '/usr/local/virtualenvs/myapp/lib64/python34.zip', '/usr/local/virtualenvs/myapp/lib64/python3.4', '/usr/local/virtualenvs/myapp/lib64/python3.4/plat-linux', '/usr/local/virtualenvs/myapp/lib64/python3.4/lib-dynload', '/usr/lib64/python3.4', '/usr/lib/python3.4', '/usr/local/virtualenvs/myapp/lib/python3.4/site-packages']
sys.version=3.4.8 (default, Mar 23 2018, 10:04:27)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
sys.prefix=/usr/local/virtualenvs/myapp
mod_wsgi.version=(4, 5, 24)
mod_wsgi.process_group: mywsgiapp
mod_wsgi.application_group:
The Apache httpd.conf didn't change. Relevant lines:
LoadModule wsgi_module "/usr/local/virtualenvs/myapp/lib64/python3.4/site-packages/mod_wsgi/server/mod_wsgi-py34.cpython-34m.so"
WSGIDaemonProcess mywsgiapp python-home=/usr/local/virtualenvs/myapp python-path=/usr/local/virtualenvs/myapp/wsgiapp
WSGIProcessGroup mywsgiapp
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /myapp /usr/local/virtualenvs/myapp/wsgiapp/wsgi.py process-group=mywsgiapp application-group=%{GLOBAL}
I'm not sure what caused this to break. I know this usually happens when mod_wsgi is compiled for the wrong version of python. But this was working fine before and everything still appears to be configured correctly: mod_wsgi is functioning, the output from the wsgi.py indicates it is using the correct version of python, and the site-packages directory of the virtualenv is in the python-path.
I have mod_wsgi installed in the main python3.4 location and tried pointing the Apache LoadModule at that instance but still get the same errors.
What else should I check?
Should sys.executable be pointing to the virtualenv instead of the main python install? Should I pip uninstall all the modules and start over?
Also, to install pandas, I had to install Cython, which in turn required that I install gcc-c++ (sudo yum install gcc-c++). Would that affect anything?
Edited to add error traces. I uncommented the line a = np.arange(15).reshape(3, 5) in the above wsgi.py file.
HTTP Error Page from Apache:
Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator at
root#localhost to inform them of the time this error occurred,
and the actions you performed just before this error.
More information about this error may be available
in the server error log.
Apache error log (note I x'ed out the IP address before posting here):
[Thu Jul 12 23:01:15.664941 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] mod_wsgi (pid=21490): Exception occurred processing WSGI script '/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py'.
[Thu Jul 12 23:01:15.727450 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] Traceback (most recent call last):
[Thu Jul 12 23:01:15.727814 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] File "/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py", line 14, in application
[Thu Jul 12 23:01:15.727831 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] a = np.arange(15).reshape(3, 5)
[Thu Jul 12 23:01:15.727865 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] AttributeError: 'module' object has no attribute 'arange'
Error when trying to show np.file:
[Thu Jul 12 23:25:59.196534 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353] mod_wsgi (pid=22747): Exception occurred processing WSGI script '/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py'.
[Thu Jul 12 23:25:59.257214 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353] Traceback (most recent call last):
[Thu Jul 12 23:25:59.257500 2018] [wsgi:error] [pid 22747] [remote 10.x.x:60353] File "/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py", line 23, in application
[Thu Jul 12 23:25:59.257535 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353] output += '\\n\\nnumpy file location='+str(np.__file__)
[Thu Jul 12 23:25:59.257569 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353] AttributeError: 'module' object has no attribute '__file__'
Also, just for reference, importing the modules works just fine if I activate the virtualenv and use the interpreter:
Python 3.4.8 (default, Mar 23 2018, 10:04:27)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__file__
'/usr/local/virtualenvs/myapp/lib/python3.4/site-packages/numpy/__init__.py'
Printing dir(np) from the wsgi.py file results in:
dir(np)=['__doc__', '__loader__', '__name__', '__package__', '__path__', '__spec__']
So it doesn't error out, but it is not the full list of identifiers. Running dir(np) from the virtualenv interpreter results in:
['ALLOW_THREADS', 'AxisError', 'BUFSIZE', 'CLIP', 'ComplexWarning', 'DataSource', 'ERR_CALL', ..... clipped for brevity - there's a full screen of items in the list
Since it does list some identifiers, here are the results of printing each of them from within wsgi.py. It does seem to be picking up the package from the correct path.
np.__path__ =_NamespacePath(['/usr/local/virtualenvs/myapp/lib/python3.4/site-packages/numpy'])
np.doc=None
np.loader=<_frozen_importlib._NamespaceLoader object at 0x7f83b82e0c88>
np.package=numpy
np.name=numpy
np.Spec=ModuleSpec(name='numpy', loader=None, origin='namespace', submodule_search_locations=_NamespacePath(['/usr/local/virtualenvs/myapp/lib/python3.4/site-packages/numpy']))
Just to be sure wsgi/python is truly finding the numpy package, I changed the wsgi.py file to import a non-existent package import foo as np, and when I ran it again it errored out with ImportError: No module named 'foo'. So it does seem to be actually finding the site-packages... but just not fully loading them?
Fun fact: when pip installs a new module it sets the permissions such that the user is able to import and use the modules as expected but "other" permissions allow the modules to be seen but not execute. Thus, mod_wsgi running under Apache was able to import the modules but calling any methods resulted in an error.
Solution: double check permissions after installing or updating python modules! I set all directories to 755 and all files to 644 and that seemed to work. Or, as mentioned in the comment, ensure that your umask is set appropriately before running pip.
I am running an apache server with MAMP in my Macbook pro. And I have added a python file named File.py to the CGI-Executable directory.
Contents of File.py:
#!/usr/bin/python
import web
import json
from xml.etree.ElementTree import Element, SubElement, Comment, tostring
urls = (
'/json', 'get_json'
)
app = web.application(urls, globals())
class get_json:
def GET(self):
pyDict = {'one':1,'two':2}
web.header('Content-Type', 'application/json')
return json.dumps(pyDict)
if __name__ == "__main__":
app.run()
I have installed web.py (by running pip install web.py) in my Mac. Now when I go to browser and enter http://localhost:8888/cgi-bin/File.py/json it is showing error 500 internal error, I checked the log file, log is
[Thu Mar 17 00:31:20 2016] [error] [client ::1] Traceback (most recent call last):
[Thu Mar 17 00:31:20 2016] [error] [client ::1] File " path-to-CGI-Executables/File.py", line 3, in <module>
[Thu Mar 17 00:31:20 2016] [error] [client ::1] import web
[Thu Mar 17 00:31:20 2016] [error] [client ::1] ImportError: No module named web
[Thu Mar 17 00:31:20 2016] [error] [client ::1] Premature end of script headers: File.py
Now I tried running the python file from terminal like
$ python File.py 127.0.0.1
Then in browser http://127.0.0.1:8080/json its working fine and showing {"two": 2, "one": 1} as result.
Whats happening if I add this to MAMP CGI? How to make installed modules available within MAMP?
UPDATE:
MAMP version : Version 3.5 (3.5)
Python version : Python 2.7.11 Mac
OS X version : 10.10.5 (14F1605)
I was getting started with AWS' Elastic Beanstalk.
I am following this tutorial to deploy a Django/PostgreSQL app.
I did everything before the 'Configuring a Database' section. The deployment was also successful but I am getting an Internal Server Error.
Here's the traceback from the logs:
mod_wsgi (pid=30226): Target WSGI script '/opt/python/current/app/polly/wsgi.py' cannot be loaded as Python module.
[Tue Sep 15 12:06:43.472954 2015] [:error] [pid 30226] [remote 172.31.14.126:53947] mod_wsgi (pid=30226): Exception occurred processing WSGI script '/opt/python/current/app/polly/wsgi.py'.
[Tue Sep 15 12:06:43.474702 2015] [:error] [pid 30226] [remote 172.31.14.126:53947] Traceback (most recent call last):
[Tue Sep 15 12:06:43.474727 2015] [:error] [pid 30226] [remote 172.31.14.126:53947] File "/opt/python/current/app/polly/wsgi.py", line 12, in <module>
[Tue Sep 15 12:06:43.474777 2015] [:error] [pid 30226] [remote 172.31.14.126:53947] from django.core.wsgi import get_wsgi_application
[Tue Sep 15 12:06:43.474799 2015] [:error] [pid 30226] [remote 172.31.14.126:53947] ImportError: No module named django.core.wsgi
Any idea what's wrong?
Have you created a requirements.txt in the root of your application? Elastic Beanstalk will automatically install the packages from this file upon deployment. (Note it might need to be checked into source control to be deployed.)
pip freeze > requirements.txt
(You will probably want to do that from within a virtualenv so that you only pick up the packages your app actually needs to run. Doing that with your system Python will pick up every package you've ever installed system-wide.)
The answer (https://stackoverflow.com/a/47209268/6169225) by carl-g is correct. One thing that got me was that requirements.txt was in the wrong directory. Let's say you created a django project called mysite. This is the directory in which you run the eb command(s) --> make sure requirements.txt is in this directory.
If you forget the .ebextensions folder you will get the same error.
I was following along with a good simple (non Elastic Beanstalk) tutorial and missed step 3 & 4 of Elastic Beanstalk.
I was using Django 1.11 and Python 2.7
THE ISSUE
The problem: it seems like the tagging module which I have in my /srv/python-environments/saltycrane/lib/python2.5/site-packages/tagging is not being included because I upgraded the system to 2.6, despite my assumption of relying on 2.5 in virtualenv mode.
Here's the error in /var/log/apache2/error.log:
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] mod_wsgi (pid=10470): Exception occurred processing WSGI script '/srv/workarounds/apache/django.wsgi'.
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] Traceback (most recent call last):
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] File "/usr/lib/pymodules/python2.6/django/core/handlers/wsgi.py", line 241, in __call__
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] response = self.get_response(request)
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] File "/usr/lib/pymodules/python2.6/django/core/handlers/base.py", line 141, in get_response
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] return self.handle_uncaught_exception(request, resolver, sys.exc_info())
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] File "/usr/lib/pymodules/python2.6/django/core/handlers/base.py", line 176, in handle_uncaught_exception
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] if resolver.urlconf_module is None:
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] File "/usr/lib/pymodules/python2.6/django/core/urlresolvers.py", line 239, in _get_urlconf_module
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] self._urlconf_module = import_module(self.urlconf_name)
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] File "/usr/lib/pymodules/python2.6/django/utils/importlib.py", line 35, in import_module
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] __import__(name)
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] File "/srv/workarounds/urls.py", line 3, in <module>
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] from tagging.views import tagged_object_list
[Thu Mar 24 00:08:35 2011] [error] [client 127.0.0.1] ImportError: No module named tagging.views
MY SETUP
Firstly, here's my setup:
$ python --version
Python 2.6.6
$ python
>>> import django
django.VERSION
(1, 2, 3, 'final', 0)
My django projects live in /srv. My virtual envs live in /srv/python-environments
If I cd into /srv/ and do:
source python-environments/saltycrane/bin/activate
The python version becomes:
$ python --version
Python 2.5.2
My project, /srv/workarounds uses /srv/workarounds/apache/django.wsgi, which is composed of:
import os, sys, site
virtualenv = '/srv/python-environments/saltycrane/'
ALLDIRS = [os.path.join(virtualenv, 'lib', 'python%s' % sys.version[:3], 'site-packages')]
# Remember original sys.path.
prev_sys_path = list(sys.path)
# Add project directory
sys.path.append( '/srv/' )
sys.path.append( '/srv/workarounds/' )
for directory in ALLDIRS:
site.addsitedir( directory )
new_sys_path = []
for item in list(sys.path):
if item not in prev_sys_path:
new_sys_path.append(item)
sys.path.remove(item)
sys.path[:0] = new_sys_path
os.environ['DJANGO_SETTINGS_MODULE'] = 'workarounds.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
The code basically adds /srv/ and /srv/workarounds to the python path when the wsgi is run by Apache.
SO....
How can I adjust my wsgi to keep using Python 2.5.2 instead of 2.6? Or if not, how can I update my virtualenv to use python 2.6 packages with pip?
THINGS IM NOT SURE ABOUT
Perhaps it runs on 2.6 and does grab the tagging module, but the tagging module or a part of it isn't compatible, therefore that's why it complains of No module named tagging.views ?
Maybe this has nothing to do with 2.5 to 2.6 and was always present? But I doubt this very much because I did several restarts with that code in place, and it worked fine.
It could have been a Django subtle version update, I might have updated 1.1 or 1.2beta to 1.2.3 final.
EDIT: If I have the right mod_wsgi.so, it's compiled for 2.6.
/usr/lib/apache2/modules$ ldd mod_wsgi.so
linux-gate.so.1 => (0xf57fe000)
libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb760f000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb75f6000)
libdl.so.2 => /lib/libdl.so.2 (0xb75f2000)
libutil.so.1 => /lib/libutil.so.1 (0xb75ed000)
libm.so.6 => /lib/libm.so.6 (0xb75c7000)
libc.so.6 => /lib/libc.so.6 (0xb7482000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7438000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb72e0000)
libz.so.1 => /usr/lib/libz.so.1 (0xb72cc000)
/lib/ld-linux.so.2 (0xb788e000)
I think if you changed this it might work:
ALLDIRS = [os.path.join(virtualenv, 'lib', 'python%s' % sys.version[:3], 'site-packages')]
to
ALLDIRS = [os.path.join(virtualenv, 'lib', 'python2.5', 'site-packages')]
Setting your WSGIPythonHome is what is suggested when using virtualenv with modwsgi:
virtualenv --no-site-packages --python=python2.5 BASELINE
and setup modwsgi to use that as the wsgipythonhome
Baseline Environment
The first step in using virtual
environments with mod_wsgi is to point
mod_wsgi at a baseline Python
environment. This step is actually
optional and if not done the main
Python installation for the system,
usually that which mod_wsgi was
compiled for, would be used as the
baseline environment.
Although the main Python installation
can be used, especially in a shared
environment where daemon mode of
mod_wsgi is used to host WSGI
applications for different users, it
is better to make the baseline
environment a virgin environment with
an effectively empty 'site-packages'
directory. This way there is no
possibility of conflicts between
modules and packages in a users
individual Python virtual environment
and the baseline environment.
To create a virgin environment using
the 'virtualenv' program, the
'--no-site-packages' option should be
supplied when creating the
environment.
$ cd /usr/local/pythonenv
$ virtualenv --no-site-packages BASELINE
New python executable in BASELINE/bin/python
Installing setuptools............done.
Note that the version of Python from
which this baseline environment is
created must be the same version of
Python that mod_wsgi was compiled for.
It is not possible to mix environments
based on different major/minor
versions of Python.
Once the baseline Python environment
has been created, the WSGIPythonHome
directive should be defined within the
global part of the main Apache
configuration files. The directive
should refer to the top level
directory for the baseline environment
created by the 'virtualenv' script.
WSGIPythonHome /usr/local/pythonenv/BASELINE
This Python environment will now be
used as the baseline environment for
all WSGI applications running under
mod_wsgi, whether they be run in
embedded mode or daemon mode.
There is no need to set the
WSGIPythonHome directive if you want
to use the main Python installation as
the baseline environment.