Short version:
It is now failing to import flask and Apache still seems to think it's loading the system's python3.6 installation on start up instead of the venv's 3.8: ([mpm_prefork:notice] [pid 19662] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 mod_wsgi/4.5.17 Python/3.6 configured).
However sys.executable returns the correct path for the venv.
Much longer version:
I have several virtualhosts on my Apache2/LAMP installation. Most of these just run PHP.
A while back I started looking at Flask and created a really simple API and it worked fine. More recently I wanted a second flask-based site and so created a new virtualhost and set up a venv in it using predominantly this tutorial.
I had a brief bizarre issue where Apache wouldn't run it with the venv but ran it using the global python3 installation and was unable to import the Flask module (as it was not present in the global installation). I fixed this by setting WSGIDaemonProcess newproject python-home=/var/www/newproject/env/bin, rather than /var/www/newproject/env/ and for whatever reason this fixed it, despite the older project working just fine with the latter. For clarity the venv is python3.8.12.
Everything has been fine until I got around to certbot'ing it to get SSL working. I had to move WSGIDaemonProcess and WSGIScriptAlias outside of the <VirtualHost *:80/443> blocks for it to start working again.... and then I used a python3.6+ feature. f-strings. 500 Internal error.
According to the error log, the interpretter had no idea what an f-string was, at which point I realised it was using the global 3.5 installation and must be somehow importing modules from the venv's site-packages which is why the previous fix "fixed" it. (? just a guess)
After attempting to follow various discussions on fixing this I discovered that Ubuntu 16.04 is just too old and the deadsnakes:ppa no longer supports it, so I couldn't install things like python3.8-dev, so things like pip install mod_wsgi didn't work. So I have updated Ubuntu to the next LTS. (18.04). Python3.5 is gone, replaced by 3.6. Now it doesn't error on f-strings! However it is still not using the venv.
Also, since the Ubuntu update, the apache error.log has been spammed with this:
Current thread 0x00007f9477e23bc0 (most recent call first):
[Sat Feb 12 15:45:21.449866 2022] [core:notice] [pid 19151] AH00052: child pid 19236 exit signal Aborted (6)
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'
As far as I can tell, every global and venv installation of python is able to import encodings just fine, so I have no idea what that's about.
I have tried all sorts. Below is the set of currently in-place "fixes" I have tried.
- Setting all the following at the top of the
.conf:
WSGIDaemonProcess newproject python-home=/var/www/newproject/env/bin
WSGIScriptAlias / /var/www/newproject/app.wsgi process-group=newproject application-group=%{GLOBAL}
WSGIPythonHome /var/www/newproject/env
- Setting
#!/var/www/newproject/env/bin/pythonat the top ofapp.wsgi
These led to print(sys.executable) saying that it was pointing to the project directory, but in the log after a restart Apache reports: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 mod_wsgi/4.5.17 Python/3.6 configured. So Still the wrong version of Python, aka the system version that python3 is associated with.
- Tried following these instructions, however at the point that then refers to yet more instructions regarding installing mod_wsgi for my particular python version. I
apt remove libapache2-mod-wsgi-py3as it says and apparently successfullypip install mod_wsgi. However Those instructions then make you insert a reference to a particular venv into Apache'smods-available, when I have multiple venvs for different virtualhosts, so surely that can't work if I ever want a separate project (which I already do)?
Regardless, it is too late to not do it and I don't know how to undo it. Now WSGI has been disabled due to uninstalling the above package as noted, and apache won't restart without error:
systemctl status apache2.service
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: failed (Result: exit-code) since Sat 2022-02-12 15:19:29 UTC; 18min ago
Process: 18727 ExecStop=/usr/sbin/apachectl stop (code=exited, status=1/FAILURE)
Process: 17896 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
Process: 18735 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
Main PID: 3921 (code=exited, status=0/SUCCESS)
Feb 12 15:19:29 scw-cafeb1 systemd[1]: Starting The Apache HTTP Server...
Feb 12 15:19:29 scw-cafeb1 apachectl[18735]: apache2: Syntax error on line 140 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/wsgi
Feb 12 15:19:29 scw-cafeb1 apachectl[18735]: Action 'start' failed.
Feb 12 15:19:29 scw-cafeb1 apachectl[18735]: The Apache error log may have more information.
Feb 12 15:19:29 scw-cafeb1 systemd[1]: apache2.service: Control process exited, code=exited status=1
Feb 12 15:19:29 scw-cafeb1 systemd[1]: apache2.service: Failed with result 'exit-code'.
Feb 12 15:19:29 scw-cafeb1 systemd[1]: Failed to start The Apache HTTP Server.
Line 140 of apache2.conf is IncludeOptional mods-enabled/*.load
Everything is broken, including the original project that used to work. Where do I even start fixing all this? I'm blatantly too inexperienced with all this to know where to go now. I am very happy to remove any unneeded python versions. Installed globally is 2.7, 3.6, and 3.8.
Update: I reinstalled libapache2-mod-wsgi-py3 with apt, I'm back to 500 internal errors like before. It's now erroring on importing Flask, presumably because there's no global flask installation for any python version, only within the venv, even though sys.executable still returns the expected venv executable. I am confused.
If you'd like me to dump all the various config files let me know and I'll pastebin link to them all. Lastly, I do have an image from just before I did the Ubuntu update so if everything truly is unrecoverable then I could revert at least to when mod_wsgi wasn't also broken/removed.
