On Sun, May 12, 2024 at 10:57 PM Graham Dumpleton <
graham.dumple...@gmail.com> wrote:
>
> 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.
>
> Installing a custom Python version into a Docker image.
> blog.dscpl.com.au
>
> Also, where is LoadFile line in Apache picking up mod_wsgi.so from?
>
> Graham

I don't intend to build from source again if I can help it. That was a
PITA. 😄 I only did it way back since I believe at the time Python 3.11
wasn't available as a package for Devuan/Debian yet...? I honestly don't
remember. Thank you for the link though if I ever do need. 🙂

I had been just doing "service apache2 restart" yeah, but I just tried a
proper stop, then a start, and the state is the same. 😑

So best I can tell this is where I'm at:

   - CLI-run Python, the older site, and new site, have identical paths
   except for the first entry (CLI = '', apps = their app dir)
   - Both apps don't import cmath and a bunch of other modules but the CLI
   Python does
   - All prefixes point to the correct virtual env root
   - The old app still runs even after a full stop and start of Apache

I apologize for all this. I don't have any idea what's going on and I've
tried everything I can think of, what you've asked / suggested, and it's
still breaking my brain.

- Alastair

> On 13 May 2024, at 3:35 PM, A McBain <mcbain....@gmail.com> wrote:
>
> On Sun, May 12, 2024 at 10:22 PM A McBain <mcbain....@gmail.com> wrote:
>
>
> On Sun, May 12, 2024 at 10:05 PM A McBain <mcbain....@gmail.com> wrote:
>
>
> On Sun, May 12, 2024 at 9:47 PM Graham Dumpleton
> <graham.dumple...@gmail.com> wrote:
>
>
>
>
> On 13 May 2024, at 2:33 PM, A McBain <mcbain....@gmail.com> 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 <
graham.dumple...@gmail.com> wrote:
>
>
>
> On 13 May 2024, at 2:02 PM, A McBain <mcbain....@gmail.com> 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
modwsgi+unsubscr...@googlegroups.com.
> 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 modwsgi+unsubscr...@googlegroups.com.
> 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
modwsgi+unsubscr...@googlegroups.com.
> 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 modwsgi+unsubscr...@googlegroups.com.
> 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 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
modwsgi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/modwsgi/55163B95-DCAF-4129-BD81-4D477F4FC9F6%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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/CAGV_ScrciAyspmA4NyZA%3Dne%3Da5MaDvQsqr6LGmog09idZ9Ty8w%40mail.gmail.com.

Attachment: favicon.ico
Description: Binary data

Reply via email to