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.
