> > I confirmed version matching with: > > ldd > /home/my-username/public_html/rrfexpire/venv/lib/python2.7/site-packages/mod_wsgi/server/mod_wsgi-py27.so > > which returned: > > libpython2.7.so.1.0 => /usr/local/bin/anaconda/lib/libpython2.7.so.1.0 > > This suggests you have install Anaconda Python in the strangest non > standard place. > > If you run Anaconda Python command line and do: > > import sys > print(sys.prefix) > > what do you get? > I would suggest it is a bad idea to be installing the whole Anaconda > Python installation under /usr/local/bin as that path suggests. >
>From Anaconda Python console, sys.prefix reports: >>> sys.prefix '/usr/local/bin/anaconda' And yes, I absolutely believe that this server has many non-standard installations. I don't know the whole history, but do know a lot of amateurs like myself have been involved in this server setup. my rrfexpire.wsgi: > > > activate_this = > '/home/my-username/public_html/rrfexpire/venv/bin/activate_this.py' > with open(activate_this) as file_: > exec(file_.read(), dict(__file__=activate_this)) > import sys > sys.path.insert(0, '/home/my-username/public_html/rrfexpire/venv') > from rrfexpire import app as application > > > Shouldn't need to do activation in the WSGI script file. > Thanks, I have had this thought from reading documentation, but was afraid to deviate from the Flask docs. I confirmed it works without activation. > In httpd.conf, previous users have working flask apps configured as: > > > WSGIPythonHome /usr/local/bin/anaconda3 > > This path looks wrong. > > Presuming you the output from ldd is correct, this should be: > > WSGIPythonHome /usr/local/bin/anaconda > Good catch, but previous apps did actually use this Anaconda3 Python. I decided to go with the Python2 Anaconda after starting my learning with Python2 > But then, you should really disable use of mod_wsgi embedded mode > altogether and set the Python installation home directory on > WSGIDaemonProcess instead. > So what you want is to start with what you have below, but very > importantly, add: > > WSGIRestrictEmbedded On > > outside of any VirtualHost. Best place is probably directly after > LoadModule line for mod_wsgi. > I implemented these changes and confirmed that existing apps still work. > Just to be absolutely sure you are picking up correct Python shared > library, and that your ldd isn't only working because LD_LIBRARY_PATH is > set in your environment for your user (which wouldn't be set for Apache), > just before the LoadModule line, add: > > LoadFile /usr/local/bin/anaconda/lib/libpython2.7.so.1.0 > > For my app, I tried to contain it in a VirtualHost: > > VirtualHost *> > ServerName lelrdaapps01.city.Tech.com:80 > <http://lelrdaapps01.city.tech.com:80> > > > > ErrorLog /home/my-username/public_html/rrfexpire/error.log > > LogLevel debug > > > > WSGIDaemonProcess rrfexpire > python-home=/home/my-username/public_html/rrfexpire/venv > python-path=/home/my-username/public_html/rrfexpire/venv/lib/python2.7/site-packages/ > > user=apache group=apache > > > You don't need: > > user=apache group=apache > > as default config will run it as whatever Apache user is anyway. > > You should not need the 'path=...' option at all. > > The 'python-home' option needs to be whatever 'sys.prefix' for virtual > environment is, which looks okay with what you have, but check it. > I updated these as described with no additional faults. > So if you are still loading the system mod_wsgi package, which is going to > be compiled for system Python and not Anaconda Python, then none of this > will work. > > The mod_wsgi you load must be the one that was compiled for Anaconda > Python. You cannot force mod_wsgi compiled for one Python > installation/version, to use a different Python installation/version. > This refers to the "LoadModule" directives in the httpd.conf, right? I updated that to point to the mod_wsgi compiled for my venv as: LoadModule wsgi_module /home/neildillon/public_html/rrfexpire/venv/lib/python2.7/site-packages/mod_wsgi/server/mod_wsgi-py27.so And now everything seems to be working appropriately for my Flask App, with no module import errors as was typical before. This makes me believe that everything is linked correctly and I can continue to work on my app. > > If you can't stop using the system mod_wsgi package, you should use > mod_wsgi-express (start-server) to run a separate instance of > Apache/mod_wsgi for Python version you need. Then setup the main Apache to > proxy requests through to that separate instance. > However, updating the "LoadModule wsgi_module" as mentioned above breaks the previous apps that ran wsgi_mod. I'm afraid that I will need them to still work, so can't permanently update the wsgi_module to the version that works for me. Is it correct that only one version of wsgi_module can run at a time? I thought that was the point of running the virtualenv's - so that multiple instances of python interpreters with corresponding mod_wsgi compilations can run in parallel? Or is that when I need to move on to mod_wsgi-express, and proxy with Apache? Finally, I see in the documentation many examples of running mod_wsgi-express through the shell, but can't yet tell how to implement that through myapp.wsgi in the Flask context. I'm sure I need to master the Apache proxy documentation and will start with that, but any other recommended resources would be appreciated. > Can you confirm that you are still loading the system mod_wsgi and not one > you compiled for Anaconda Python? > Yes, at the time of the original message, I was still loading the system mod_wsgi, and not the one compiled for Anaconda Python. I understand now that this is a directive that is entered in the Apache config file. -- 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.
