Ensure you do a complete stop and start of Apache and not just reload or restart in case Apache had cached a reference to a broken Python library variant from your self compiled build.
If going to build your own Python from source code ensure you read. A bit dated, but still relevant. Ignore that talks about Docker, still applies for any Python build. http://blog.dscpl.com.au/2015/06/installing-custom-python-version-into.html Also, where is LoadFile line in Apache picking up mod_wsgi.so <http://mod_wsgi.so/> from? Graham > On 13 May 2024, at 3:35 PM, A McBain <[email protected]> wrote: > > On Sun, May 12, 2024 at 10:22 PM A McBain <[email protected] > <mailto:[email protected]>> wrote: >> >> On Sun, May 12, 2024 at 10:05 PM A McBain <[email protected]> wrote: >>> >>> On Sun, May 12, 2024 at 9:47 PM Graham Dumpleton >>> <[email protected]> wrote: >>>> >>>> >>>> >>>> On 13 May 2024, at 2:33 PM, A McBain <[email protected]> wrote: >>>> >>>> The old one is running on the same physical server, just with its own >>>> Apache config and own subdomain. As to having multiple things running, >>>> that's why I set WSGIApplicationGroup to %{SERVER} but just in case I >>>> changed it explicitly to "enfilade.asmcbain.net" (no effect, but shouldn't >>>> hurt anything to keep the change). >>>> >>>> >>>> The WSGIApplicationGroup directive sets which Python interpreter context >>>> is used. It is distinct from the daemon process group. >>>> >>>> You want each WSGI application instance to run in a different mod_wsgi >>>> daemon process group if using the main Python interpreter context >>>> (application group %{GLOBAL}). >>>> >>>> So what you want is for each VirtualHost to use a different named mod_wsgi >>>> dameon process group. >>>> >>>> <VirtualHost ...> >>>> ServerName site-1.example.com >>>> WSGIDaemonProcess site-1 \ >>>> user=asmcbain group=asmcbain \ >>>> display-name='%{GROUP}' \ >>>> lang='en_US.UTF-8' \ >>>> locale='en_US.UTF-8' \ >>>> threads=5 \ >>>> queue-timeout=45 \ >>>> socket-timeout=60 \ >>>> connect-timeout=15 \ >>>> request-timeout=60 \ >>>> inactivity-timeout=0 \ >>>> startup-timeout=15 \ >>>> deadlock-timeout=60 \ >>>> graceful-timeout=15 \ >>>> eviction-timeout=0 \ >>>> restart-interval=0 \ >>>> shutdown-timeout=5 \ >>>> maximum-requests=0 \ >>>> python-home=/home/asmcbain/enfilade/.env \ >>>> python-path=/home/asmcbain/enfilade >>>> WSGIProcessGroup site-1 >>>> WSGIApplicationGroup %{GLOBAL} >>>> WSGIScriptAlias / /home/asmcbain/enfilade/atcid/wsgi.py >>>> </VirtualHost> >>>> >>>> <VirtualHost ...> >>>> ServerName site-2.example.com >>>> WSGIDaemonProcess site-2 \ >>>> user=asmcbain group=asmcbain \ >>>> display-name='%{GROUP}' \ >>>> lang='en_US.UTF-8' \ >>>> locale='en_US.UTF-8' \ >>>> threads=5 \ >>>> queue-timeout=45 \ >>>> socket-timeout=60 \ >>>> connect-timeout=15 \ >>>> request-timeout=60 \ >>>> inactivity-timeout=0 \ >>>> startup-timeout=15 \ >>>> deadlock-timeout=60 \ >>>> graceful-timeout=15 \ >>>> eviction-timeout=0 \ >>>> restart-interval=0 \ >>>> shutdown-timeout=5 \ >>>> maximum-requests=0 \ >>>> python-home=/home/asmcbain/enfilade/.env \ >>>> python-path=/home/asmcbain/enfilade >>>> WSGIProcessGroup site-2 >>>> WSGIApplicationGroup %{GLOBAL} >>>> WSGIScriptAlias / /home/asmcbain/enfilade/atcid/wsgi.py >>>> </VirtualHost> >>>> >>>> So each site should have different name to WSGIDaemonProcess, with >>>> matching WSGIProcessGroup, and WSGIApplicationGroup should be %{GLOBAL} >>>> for both, not {SERVER}. >>>> >>>> The {SERVER} value has a different meaning and best avoiding it. >>>> >>>> So lets make sure each is running in separate daemon process groups. >>>> >>>> BTW, also make sure that somewhere outside of all VirtualHost definitions >>>> you add: >>>> >>>> WSGIRestrictEmbedded On >>> >>> OK, I updated both the old site and the new one to make >>> WSGIApplicationGroup %{GLOBAL}. They always had different >>> WSGIProcessGroup values. >>> >>> I also added WSGIRestrictEmbedded to the base Apache config. >>> >>> Apache restarts fine, and the old site loads up but the new one still >>> prints the import math error even after the changes. 😕 >>> >>> I've attached the relevant bits to both. >>> >>> - Alastair >> >> Originally I'd compiled this Python 3.11 myself, but I've just double >> checked and verified Python 3.11 and the -dev package are from >> official packages and not my own manual build+install. >> >> I also checked that inside or outside of the virtual env (results are >> the same) I can run the Python interpreter shell and do: >> >> import math >> math.ceil(1.1) >> >> I don't get any errors. >> >> - Alastair > > Update to that. The modules loaded are different between the daemon > one and the regular interpreter. > > Doing "print(sys.builtin_module_names)" results in the following for > the daemon version: > > [Sun May 12 22:31:33.744235 2024] [wsgi:error] [pid 7430:tid > 140134038087360] ('_abc', '_ast', '_codecs', '_collections', > '_functools', '_imp', '_io', '_locale', '_operator', '_signal', > '_sre', '_stat', '_string', '_symtable', '_thread', '_tokenize', > '_tracemalloc', '_warnings', '_weakref', 'atexit', 'builtins', > 'errno', 'faulthandler', > 'gc', 'itertools', 'marshal', 'posix', 'pwd', 'sys', 'time', 'xxsubtype') > > And this substantially longer list for the one I just run from the CLI myself: > > ('_abc', '_ast', '_bisect', '_blake2', '_codecs', '_collections', > '_csv', '_datetime', '_elementtree', '_functools', '_heapq', '_imp', > '_io', '_locale', '_md5', '_opcode', '_operator', '_pickle', > '_posixsubprocess', '_random', '_sha1', '_sha256', '_sha3', '_sha512', > '_signal', '_socket', '_sre', '_stat', '_statistics', '_string', > '_struct', '_symtable', '_thread', '_tokenize', '_tracemalloc', > '_warnings', '_weakref', 'array', 'atexit', 'binascii', 'builtins', > 'cmath', 'errno', 'faulthandler', 'fcntl', 'gc', 'grp', 'itertools', > 'marshal', 'math', 'posix', 'pwd', 'pyexpat', 'select', 'spwd', 'sys', > 'syslog', 'time', 'unicodedata', 'xxsubtype', 'zlib') > > Now I just have to figure out why. > >>> >>>> >>>> This will cause an error if mod_wsgi daemon process groups aren't being >>>> configured properly. >>>> >>>> Graham >>>> >>>> >>>> This is the result of the wsgi.prod.py printouts: >>>> >>>> [Sun May 12 21:29:11.788518 2024] [wsgi:error] [pid 5671:tid >>>> 140047682610880] sys.prefix '/home/asmcbain/enfilade/.env' >>>> [Sun May 12 21:29:11.788639 2024] [wsgi:error] [pid 5671:tid >>>> 140047682610880] sys.path ['/home/asmcbain/enfilade', >>>> '/usr/lib/python311.zip', '/usr/lib/python3.11', >>>> '/usr/lib/python3.11/lib-dynload', >>>> '/home/asmcbain/enfilade/.env/lib/python3.11/site-packages'] >>>> >>>> Alastair >>>> >>>> On Sun, May 12, 2024 at 9:24 PM Graham Dumpleton >>>> <[email protected]> wrote: >>>>> >>>>> >>>>> On 13 May 2024, at 2:02 PM, A McBain <[email protected]> wrote: >>>>> >>>>> >>>>> Hi, I looked at previous messages and others on StackOverflow but none >>>>> seem to solve my issue. >>>>> >>>>> I have an app I wrote working perfectly fine under Python 3.11 with >>>>> mod_wsgi and Apache 2. >>>>> >>>>> I did a bunch of development on the app (upgraded django, new features), >>>>> and set up a new checkout of that on my server, with its own virtual >>>>> environment (using venv). It uses effectively the same config (different >>>>> subdomain) in Apache2 as the original older copy, but the new one fails >>>>> with an import error while the old one is still chugging along. >>>>> >>>>> >>>>> When you say "old one is still chugging along" can you confirm you are >>>>> saying that the existing one is still running on the same server at the >>>>> same time, or it is a completely new server you have set up. >>>>> >>>>> I double checked the instructions at >>>>> https://docs.djangoproject.com/en/5.0/howto/deployment/wsgi/modwsgi/ >>>>> >>>>> I've also re-verified the mod_wsgi I installed (via pip) matches the >>>>> Python version I'm using (both are Python 3.11). >>>>> >>>>> I also tried: >>>>> >>>>> Removing the python-path argument >>>>> >>>>> The mod_wsgi docs suggest I don't need that if I specify python-home? >>>>> >>>>> Removing python-path if it refers to site-packages directory of virtual >>>>> environment specified to python-home is okay as path would be redundant. >>>>> If python-path is used to tell it where your Django project is, that >>>>> still needs to stay. >>>>> >>>>> Setting WSGIApplicationGroup to %{GLOBAL} >>>>> >>>>> That is recommended, but if you are hosting multiple WSGI applications on >>>>> the same server, they would need to be delegated to different mod_wsgi >>>>> daemon process groups. >>>>> >>>>> Unfortunately the error didn't change at all after trying those. >>>>> >>>>> I've attached the relevant apache2 config section which includes all the >>>>> mod_wsgi-setup (the rest is just redirects, ssl stuff, aliases, etc.) >>>>> >>>>> I also attached the error from the log. It looks like it's trying to use >>>>> the system Python instead of the one that exists in my .env (virtual >>>>> environment) directory. >>>>> >>>>> >>>>> The virtual environment doesn't have a copy of Python stdlib files so >>>>> they are still imported from the system Python the virtual environment >>>>> was created from. The virtual environment effectively only has its own >>>>> site-packages directory. >>>>> >>>>> I'm banging my head as to why this worked before but not now so any help >>>>> is much appreciated. Thank you! 🙂 >>>>> >>>>> Other details: >>>>> >>>>> wsgi.prod.py is the default wsgi.py, just modified to load >>>>> settings.prod.py >>>>> The server is Devuan Daedalus >>>>> >>>>> >>>>> At the start of your WSGI script file add: >>>>> >>>>> import sys >>>>> print('sys.prefix', repr(sys.prefix)) >>>>> print('sys.path', repr(sys.path)) >>>>> >>>>> and check Apache logs for what paths it is using. >>>>> >>>>> Compare that to the working site. >>>>> >>>>> Post what you learn from that. >>>>> >>>>> Graham >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "modwsgi" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/modwsgi/IJp7zr6SjtY/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/modwsgi/7184C263-1522-4583-A98B-EC9806B0FA66%40gmail.com. >>>> >>>> >>>> -- >>>> 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/CAGV_ScocfNc%3DSv7W7Ha3MbrM_0wq43v8U0AM3JOuNtsfP9vK%3Dw%40mail.gmail.com. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "modwsgi" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/modwsgi/IJp7zr6SjtY/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/modwsgi/41CA1CF3-8A06-46BF-A7AE-2CA74FCC2196%40gmail.com. > > -- > 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/CAGV_ScoxJu%3DxKwijvbPjE78BnZZD4s2ppRBT0-jCErCgdr8v%2Bg%40mail.gmail.com. -- 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/55163B95-DCAF-4129-BD81-4D477F4FC9F6%40gmail.com.
