Hello Graham I realise you have probably established that there is not much more you can offer as advice. But can you shed any light on HOW the elements of sys.path are built based on the screen shot I have attached. I am going to try using VENV instead of CONDA but in a last ditch effort to understand why it is using the current directory for DLLS and Lib when all indications are that it should find them based on sys.base_prefix which is pointing to the correct directory. Knowing this may provide me with some insight as to why my first Virtual Environment using Python 3.6.5 is working as expected when I start HTTPD as a service.
Based on the log in the image it appears to me that mod_wsgi is the last element called, it finds an issue (probably evoking wsgi.py) and then shiows this detail. [image: 2021-06-13 07_44_36-Clipboard.png] On Friday, June 11, 2021 at 11:45:28 AM UTC+10 Bruce Gibbins wrote: > Thanks Graham. yes I agree it was probably a bit confusing and difficult > to explain without some screen shots. I will see if I can add those. > > But basically, I initially had (all working) Two Services one being the > default Apache HTTP Server running out of e:\tgm\bin\apache24. This was > meant to be our PRODuction instance. I then cloned this set of directories > into another set called e:\tgm\bin\apache24-dev. i then created a second > service from here and called it Apache HTTP DEV Server. Nothing in PROD has > been touched. It is still running and using Python 3.6 and Django 2.1.7 > with a matching mod_wsgi pip installed at the time. > > All of these were configured with their own set of .conf and vhosts.conf > files and I used mod_wsgi-express to generate the module configuration > lines. All of the paths were pointing to the Virtual Environment homes. > These all work and fire up without issue. > > Affectively, all I have done now is stopped the DEV service instance. > Created a new virtual env and brought all of the packages up to near > current versions to suit Django 3.x. used pip install mod_wsgi in that new > environment hopefully match up the python version with mod_wsgi. I have > then adjusted the DEV HTTPD .conf files to use the new paths. > > All of this works when I run httpd.exe from the command line starting from > the new virtual environment root (where in this case python 3.9 lives) - > Again all functional, new Django is loaded, website and web app all > functional. We even have ADFS in play and that all hangs together. > > However, as soon as I restart the DEV HTTP Server service I get the errors > and what appears to be a missing path the Lib. If I change the .CONF files > to point back to the previous python 3.6 virtual environment, the service > starts and we have our DEV platform back - just at the older versions. > > All permissions are ok and the service account can reach the virtual > environment. > > I apologise that my technical skills don't go into the depths of WSGI and > its ecosystem and I am probably confusing things. I was expecting some > challenges - but I am almost there but just can't seem to pick why the Lib > and DLLs paths are incomplete. > > I have not had any experience with the other venv solutions and was just > hoping to basically upgrade what we had already working. > > Regards > bruce > > > On Friday, June 11, 2021 at 11:11:32 AM UTC+10 Graham Dumpleton wrote: > >> Your description is a little bit confusing. You said DEV was shutdown and >> PROD started, which was working fine. You then said DEV was left as it is, >> which I presume you mean shutdown. Then you said the service doesn't start. >> >> The service for what instance doesn't start? >> >> A few warnings. >> >> Anaconda Python is a really bad choice for using in embedded systems. It >> keeps breaking guarantees around Python embedding and so often versions of >> it will not work in embedded systems. I always recommend people avoid it >> when using mod_wsgi. >> >> Next, a system service in Windows still needs to have the required >> permissions to access any Python virtual environment, plus application >> code. If it can't access the Python virtual environment, you can get errors >> like you see. >> >> Graham >> >> On 11 Jun 2021, at 10:59 am, Bruce Gibbins <[email protected]> wrote: >> >> Hi, >> >> I realise this will probably cause me some backlash from the community >> but I have an issue which I am sure is environmental but have been >> struggling for a few days to resolve. >> >> The back story is that I have successfully had Apache 2.4.37 installed on >> our server running mod_wsgi supporting an internal Django solution we are >> working on for quite some time. >> >> Apache is running as a service on this server. Python was/is deployed via >> Anaconda virtual environment.The site has been configured as a Virtual Host >> >> Everything works well. During the project life we cloned the setup into a >> DEV set of directories and created a second Windows Service to support that >> second environment. Nothing was shared in the sense that everything was >> setup and isolated in their own setr of directories. >> >> The only thing that was shared was Python via the Virtual Environment. >> mod_wsgi was PIP installed into here after ensuring all of the appropriate >> VC libraries had been installed. >> >> Apache 2.4.37 VC15 x64 was installed from an ApacheLounge binary distro. >> >> Everything as far as i can tell is x64 >> >> Earlier this month I decided it was time to upgrade Django from 2.1.7 to >> 3.x. Our Apps are fairly basic and the whole environment pretty much >> out-of-the-box. >> >> I created a new virtual environment and brought it up to Python 3.9 and >> upgraded Django and all of its dependencies at the same time. There were >> some challenges with some dependencies but I eventually got them all sorted. >> >> I did as we did before and cloned the whole Apache folder, adjusted >> httpd.conf and httpd_hosts.conf which was typically just changing the >> various path names. >> >> After stopping the existing DEV service I fired up httpd.exe from the >> command line after changing my working directory to the virtual environment >> hosting the updated python and Django site-packages. After some initial >> config issues - have it all running. The PROD service continues to run as >> well, pointing to the production version of the site using the older >> version of Django and site-packages. >> >> As the existing Apache DEV service I had previously created affectively >> points to all of these directories and nothing has changed in how it >> starts. I simply left it as is. >> >> The service will not start. When reviewing one of the logs I discovered >> what I believe to be the issue but I don't understand how to correct it as >> I believe I have done everything required for setting up mod_wsgi in >> embedded mode on Windows. >> >> The error text indicates to me that the Python standard library .DLLs and >> .Lib directories are not correctly discovered as they indicate ".\\DDLs" >> and ".\\Lib". The sys.base_prefix is correct. Because of this I then get >> the import error. I don't believe wsgi.py even gets a chance to fire up >> properly. >> >> I know there is a lot to consume here. But I have also included the >> relevant section from the httpd.conf and httpd_vhosts.conf files >> >> WSGIApplicationGroup %{GLOBAL} >> WSGIScriptAlias / "E:/tgm/sites/dev/django-agora/agora/wsgi.py" >> <Directory E:/tgm/sites/dev/django-agora/agora> >> <Files wsgi.py> >> Require all granted >> </Files> >> </Directory> >> >> *ERROR LOG* >> >> Fri Jun 11 07:33:42.249667 2021] [wsgi:info] [pid 15408:tid 592] mod_wsgi >> (pid=15408): Initializing Python. >> Python path configuration: >> PYTHONHOME = (not set) >> PYTHONPATH = (not set) >> program name = 'python' >> isolated = 0 >> environment = 1 >> user site = 1 >> import site = 1 >> sys._base_executable = 'E:\\tgm\\bin\\Apache24-DEV\\bin\\httpd.exe' >> sys.base_prefix = 'E:\\tgm\\bin\\miniconda3\\envs\\agora-v3' >> sys.base_exec_prefix = 'E:\\tgm\\bin\\miniconda3\\envs\\agora-v3' >> sys.platlibdir = 'lib' >> sys.executable = 'E:\\tgm\\bin\\Apache24-DEV\\bin\\httpd.exe' >> sys.prefix = 'E:\\tgm\\bin\\miniconda3\\envs\\agora-v3' >> sys.exec_prefix = 'E:\\tgm\\bin\\miniconda3\\envs\\agora-v3' >> sys.path = [ >> 'E:\\tgm\\bin\\miniconda3\\envs\\agora-v3\\python39.zip', >> '.\\DLLs', >> '.\\lib', >> 'E:\\tgm\\bin\\Apache24-DEV\\bin', >> ] >> Fatal Python error: init_fs_encoding: failed to get the Python codec of >> the filesystem encoding >> Python runtime state: core initialized >> ModuleNotFoundError: No module named 'encodings' >> >> *HTTPD.CONF* >> >> LoadFile "e:/tgm/bin/miniconda3/envs/agora-v3/python39.dll" >> LoadModule wsgi_module >> "e:/tgm/bin/miniconda3/envs/agora-v3/lib/site-packages/mod_wsgi/server/mod_wsgi.cp39-win_amd64.pyd" >> WSGIPythonHome "e:/tgm/bin/miniconda3/envs/agora-v3" >> >> *HTTPD-VHOSTS.CONF* >> >> WSGIApplicationGroup %{GLOBAL} >> WSGIScriptAlias / "E:/tgm/sites/dev/django-agora/agora/wsgi.py" >> <Directory E:/tgm/sites/dev/django-agora/agora> >> <Files wsgi.py> >> Require all granted >> </Files> >> </Directory> >> >> Thank-you in advance and again my apologies if I have over detailed >> things and not followed some specific requirements for the Windows >> environment. I am just after some hints as to what may lead to the >> incomplete paths being pushed into sys.path >> >> Regards >> Bruce >> >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/modwsgi/43d2c4f0-ef9b-443b-a28f-4ac52fc213c7n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/modwsgi/43d2c4f0-ef9b-443b-a28f-4ac52fc213c7n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/bb88f63d-13eb-4816-bdfa-13530a162ab4n%40googlegroups.com.
