> On 20 Oct 2016, at 10:56 AM, Shanti Suresh <[email protected]> wrote:
>
> Greetings,
>
> Thank you for your help, in advance! It has been a frustrating day.
>
> I have a virtualenv configured with Python3.4.3 on RedHat release 7.2.
>
> I configured mod_wsgi-3.4 as:
> ./configure --with-apxs=/usr/bin/apxs
> --with-python=/usr/local/dev/env/bin/python3
Are you using your own Python installation or that from the Software
Collections Library? I am presuming it is your own rather than SCL as SCL
latest is Python 3.4.2. Just want to make sure.
Anyway, even if you intend to use a virtual environment, it is often better to
still compile mod_wsgi against the main Python installation. This will avoid
complications if later want to have multiple daemon process groups using
different Python virtual environments.
So would recommend doing a:
make distclean
then rerun configure but this time use the python3 from where it was originally
installed.
> make
> sudo cp .libs/mod_wsgi.so /etc/httpd/modules/
>
> --
> My wsgi.py file reads:
> import os
> os.environ.setdefault("DJANGO_SETTINGS_MODULE",
> "knack_djangoapp.settings_temp")
>
> from django.core.wsgi import get_wsgi_application
> application = get_wsgi_application()
> --
> --
> In httpd.conf, I have:
Because best practice is to always use daemon mode, I would recommend adding
outside of VirtualHost, usually just after where the wsgi_module is loaded:
WSGIRestrictEmbedded On
This will prevent Python being initialised in the Apache child worker processes
and will only be initialised in daemon processes.
If your configuration isn’t quite right and for some reason it tries to run
stuff in embedded mode, you will now get an error saying something is wrong.
Thus helps to avoid mistakes.
> <VirtualHost *:81>
> DocumentRoot /var/www/html/dev
> ServerName dev.domain.edu
> WSGIDaemonProcess dev
> python-path=/usr/local//dev/djangoapp:/usr/local/dev/env/lib/python3.4/site-packages/
> lang='en_US.UTF-8' locale='en_US.UTF-8’
Recommend using:
WSGIDaemonProcess dev python-home=/usr/local/dev/env
python-path=/usr/local//dev/djangoapp lang='en_US.UTF-8' locale='en_US.UTF-8’
WSGIApplicationGroup %{GLOBAL}
The important bit here is using python-home to set the location of the virtual
environment. This will be what sys.prefix is set to for Python when run under
the virtual environment. Don’t set up the virtual environment using
site-packages in python-path.
The WSGIApplicationGroup is also good practice if only have one application per
daemon process group, as is recommended, as avoids problems with some third
party C extensions for Python that will not work in Python sub interpreters.
> WSGIProcessGroup dev
This is actually redundant as as process-group option on WSGIScriptAlias.
> WSGIScriptAlias / /usr/local/dev/djangoapp/wsgi.py process-group=dev
> <Directory /usr/local/dev/djangoapp/>
> <Files wsgi.py>
> Require all granted
> </Files>
> </Directory>
> </VirtualHost>
> --
>
> --
> In my vrtualenv:
> pip freeze gives:
> Django==1.8.15
> mod-wsgi==4.5.7
> --
>
> Upon starting httpd as /sbin/service httpd start, I get:
> ...Adding '/usr/local/dev/env/lib/python3.4/site-packages/' to path
> ...Target WSGI script '/usr/local/dev/djangoapp/wsgi.py' cannot be loaded as
> Python module.
> ...Exception occurred processing WSGI script
> '/usr/local/dev/djangoapp/wsgi.py'
> ...from django.core.wsgi import get_wsgi_application
> ...ImportError: No module named 'django'
>
> I greatly appreciate any and all help. I am at my wits' end. mod_wsgi seems
> to be using the system python interpreter. It is not using the virtualenv
> appropriately.
So those are things I would recommend, but how you had it should still have
worked.
What I would suggest is temporarily replace the wsgi.py file with test script
in:
http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-installation-in-use
<http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-installation-in-use>
This will log some details about the Python virtual environment being used. You
can then verify is the virtual environment you expect it to be.
Other things to check are that the user that Apache run as has access to
everything in the virtual environment. That would usually mean access to
‘others’ for files and directories.
The only other thing can think of is that SELinux is causing problems, but
doubt that as it wouldn’t be able to access the wsgi.py even if that was the
case.
So try that test WSGI script to see if correct virtual environment. Also in
Python from command line do:
import django
print(django.__file__)
and see if where Django actually is, corresponds to where you expect it to and
where mod_wsgi is looking. Modify the test script to print out the value of
sys.path to see if the directory is in the module search path if necessary.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
