Graham - That development module did, in fact, fix the problem. Thanks for the mega-quick response; I apologize for my delay.
Did you ever figure out whether this is a technical fault with mod_wsgi or Anaconda Python? -Dylan On Tuesday, September 6, 2016 at 11:27:11 AM UTC-4, Dylan Combs wrote: > So, I see that issues similar to this have been raised in the past, but > the issues resolved there do not appear to be the same as the issue as I am > seeing, so hopefully someone can let me know what I'm doing wrong here. I > have developed a workaround using what appears to be undocumented behavior > from the WSGI Module, but I am interested in understanding why seems to be > necessary. > > *System Configuration* > > - RHEL 6.8 > - httpd 2.2 > - mod_wsgi 4.5.6 compiled with: > - anaconda 4.1.1 (Python 3.5) > > I’m using Red Hat Enterprise Linux 6.8 (fully up to date) with the > standard httpd package delivered and supported for that distribution (so > httpd 2.2). I compiled mod_wsgi from source, so I’m using the latest and > greatest (4.5.6) and I performed that compilation using Python 3.5 through > Continuum.io’s Anaconda software as follows: > > > $ wget https://github.com/GrahamDumpleton/mod_wsgi/releases/tag/4.5.6 > $ tar xf 4.5.6.tar && cd 4.5.6 > $ ./configure --with-python=/opt/anaconda3/bin/python3.5 > $ LD_RUN_PATH=/opt/anaconda3/lib make > $ sudo make install > > The compilation succeeds and the module appears to be properly linked to > the appropriate Python library: > > > # ldd /etc/httpd/modules/mod_wsgi.so > linux-vdso.so.1 => (0x00007fffff9f7000) > libpython3.5m.so.1.0 => /opt/anaconda3/lib/libpython3.5m.so.1.0 ( > 0x00007f6b55b00000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6b558d7000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f6b556d3000) > libutil.so.1 => /lib64/libutil.so.1 (0x00007f6b554d0000) > librt.so.1 => /lib64/librt.so.1 (0x00007f6b552c7000) > libm.so.6 => /lib64/libm.so.6 (0x00007f6b55043000) > libc.so.6 => /lib64/libc.so.6 (0x00007f6b54caf000) > /lib64/ld-linux-x86-64.so.2 (0x00007f6b56228000) > > > *Initial Trouble* > > > When I tried to start the httpd daemon using the init script and Upstart > service command provided by RHEL, the attempt failed and I found in > /var/log/httpd/error_log (after increasing too l > evel verbosity): > > > Could not find platform independent libraries <prefix> > Could not find platform dependent libraries <exec_prefix> > Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] > [info] mod_wsgi (pid=3786): Python home /opt/anaconda3. > [info] mod_wsgi (pid=3786): Initializing Python. > [info] mod_wsgi (pid=3787): Starting process 'sampleapp' with uid=48, gid=48 > and threads=15. > [info] mod_wsgi (pid=3787): Python home /opt/anaconda3. > [info] mod_wsgi (pid=3787): Initializing Python. > Fatal Python error: Py_Initialize: Unable to get the locale encoding > ImportError: No module named 'encodings' > > And so it begins… > > > *My Quest in Directing Apache to the Anaconda Python Resources* > > > Though it appears from the log and from the documentation on mod_wsgi that > I was correctly establishing the configuration directive necessary to point > httpd to the correct location for Python resources, the error seems pretty > clearly indicative of a failure in that respect. After using every damn > WSGI directive (WSGIPythonHome, WSGIPythonPath, WSGIDaemonProcess with the > python-home or python-path options…) which seemed plausibly related, all to > no avail, I changed tactics. > > > I ruled out permission and SELinux issues through a variety of standard > means. I tried running Apache as root without SELinux enabled just to make > sure this couldn’t possibly be the problem. Just to be 100% sure and > confirm for myself my own rudimentary assessment capabilities, I even > `chmod -R 777`’d /opt/anaconda3 (not before taking a backup of it which I > then restored after the test, of course). It was clear that httpd could > access the files and do whatever it pleased with them; for some reason, > despite seeming to acknowledge clear direction, even, it just refused to > find them. > > > So I decided I’d just have to stack trace httpd and see what, exactly, is > going on. In doing so, I noticed that the httpd daemon would seem to > successfully locate the /opt/anaconda3 directory (as expected). In > performing the initial module load, it would successfully open the > necessary Python libraries. > > > open("/opt/anaconda3/lib/libpython3.5m.so.1.0", O_RDONLY) = 5 > > w00t. No issues so far. > > > However, despite the fact that mod_wsgi logs an info event indicating that > it has properly recognized the WSGIPythonHome directive I am providing > (which is accurate; it is equivalent with the sys.prefix variable, *as > the documentation indicates it should be* > <https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIPythonHome.html>), > > the startup process invariably devolves into searching what appears to be a > default series of locations for the Python resources (/usr, for example). > > > From the stack trace (my user name converted to “myusername”): > > > stat("/sbin/python3", 0x7fffa0fba600) = -1 ENOENT (No such file or > directory) > stat("/bin/python3", 0x7fffa0fba600) = -1 ENOENT (No such file or > directory) > stat("/usr/sbin/python3", 0x7fffa0fba600) = -1 ENOENT (No such file or > directory) > stat("/usr/bin/python3", 0x7fffa0fba600) = -1 ENOENT (No such file or > directory) > readlink("", 0x7fffa0fa5520, 4096) = -1 ENOENT (No such file or > directory) > open("pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or > directory) > open("pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or > directory) > stat("Modules/Setup", 0x7fffa0fa64a0) = -1 ENOENT (No such file or > directory) > getcwd("/home/myusername", 4096) = 16 > stat("/home/myusername/lib/python3.5/os.py", 0x7fffa0fa64a0) = -1 ENOENT (No > such file or directory) > stat("/home/myusername/lib/python3.5/os.pyc", 0x7fffa0fa63d0) = -1 ENOENT (No > such file or directory) > stat("/home/myusername/lib/python3.5/os.py", 0x7fffa0fa64a0) = -1 ENOENT (No > such file or directory) > stat("/home/myusername/lib/python3.5/os.pyc", 0x7fffa0fa63d0) = -1 ENOENT (No > such file or directory) > stat("/home/lib/python3.5/os.py", 0x7fffa0fa64a0) = -1 ENOENT (No such file > or directory) > stat("/home/lib/python3.5/os.pyc", 0x7fffa0fa63d0) = -1 ENOENT (No such file > or directory) > stat("/home/ilan/minonda/envs/_build/lib/python3.5/os.py", 0x7fffa0fa63d0) = > -1 ENOENT (No such file or directory) > stat("/home/ilan/minonda/envs/_build/lib/python3.5/os.pyc", 0x7fffa0fa6320) = > -1 ENOENT (No such file or directory) > write(2, "Could not find platform independ"..., 55) = 55 > stat("pybuilddir.txt", 0x7fffa0fa1440) = -1 ENOENT (No such file or > directory) > getcwd("/home/myusername", 4096) = 16 > stat("/home/myusername/lib/python3.5/lib-dynload", 0x7fffa0fa5520) = -1 > ENOENT (No such file or directory) > stat("/home/myusername/lib/python3.5/lib-dynload", 0x7fffa0fa5520) = -1 > ENOENT (No such file or directory) > stat("/home/lib/python3.5/lib-dynload", 0x7fffa0fa5520) = -1 ENOENT (No such > file or directory) > stat("/home/ilan/minonda/envs/_build/lib/python3.5/lib-dynload", > 0x7fffa0fa5520) = -1 ENOENT (No such file or directory) > write(2, "Could not find platform dependen"..., 58) = 58 > write(2, "Consider setting $PYTHONHOME to "..., 57) = 57 > > Despite that info event in /var/log/httpd/error_log showing me that mod > WSGI seems to properly recognize the information I provided with the > WSGIPythonHome directive, I never see any attempt from the software to look > to /opt/anaconda3 for the Python resources. If you’ll note, the search > becomes so desperate, in fact, that it includes some weird searches to > subdirectories and resources in the non-existant /home/ilan directory, > which looks like it must be somehow inadvertently included information on > behalf of the designer of Anaconda, as I found a forum post signed “ilan” > from him, it seems. Eventually, as you can see, the search process fails > and httpd proclaims its inability to locate the resources. > > > I noticed, however, that the search pattern being run by httpd/mod_wsgi > looks like it includes an attempt to locate Python resources using the > current working directory. So… I changed my current working directory to > /opt/anaconda3 and executed httpd manually from there and, voila, if I > start the httpd process from within the Python Home location, it works! > GLORY! IT WORKS! > > > But… I can’t exactly change the httpd default working directory to solve > this problem; that’s crazy. However, you also might have noticed in my > stack trace that one of the steps Apache was conducting in searching for > the Python resources consisted of attempts to read a pyvenv.cfg file in the > current working directory. > > > I managed to look up the simple syntax for such a file, and it is > something like this: > > > home = /opt/anaconda3 > include-system-site-packages = true > version = 3.5.2 > > In fact, it is exactly like that in my case. If I place it in the root of > the file tree (/pyvenv.cfg). That actually fixes the problem and the > application runs as expected without any errors. > > > The mod_wsgi configuration details I settled on are as follows: > > > From /etc/httpd/conf.d/awsgi.conf: > > LoadModule wsgi_module modules/mod_wsgi.so > WSGISocketPrefix /var/run/wsgi > WSGIApplicationGroup %{GLOBAL} > WSGIPythonHome /opt/anaconda3 > > And subsequently from /etc/httpd/conf.d/ssl.conf: > > > <VirtualHost _default_:443> > WSGIScriptAlias / /var/www/wsgi-scripts/scriptname.wsgi > WSGIDaemonProcess sampleapp user=apache group=apache threads=5 > WSGIProcessGroup sampleapp > ... > </VirtualHost> > > > > Pretty basic. Anyone have any ideas where I went wrong? I am, of > course, glad to attempt any suggestions with the current system and report > back on its behavior. > > -- 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.
