GOOGLE ADS

Dienstag, 12. April 2022

Apache meldet weiterhin "python error: not main interpreter" beim Ausführen von Django WSGI

Apache führt Django WSGI im Docker-Container aus. Hier die Versionen:

Apache-Version: 2.4.6

Python-Version: 3.10.4

mod_wsgi-Version: 4.9.0

Docker -Basisimage: Centos-7.9.2009

httpd-Konfiguration:

....
LoadModule wsgi_module ${APP_ROOT_DIR}/common/conf/httpd/mod_wsgi-py310.cpython-310-x86_64-linux-gnu.so
WSGIPythonHome /opt/python-3.10.4
Alias /na/static/ ${APP_ROOT_DIR}/publish/
<Directory ${APP_ROOT_DIR}>
Require all granted
</Directory>
WSGIDaemonProcess portal python-home=/opt/python-3.10.4 processes=1 threads=10 display-name=%{GROUP} umask=027 socket-timeout=600
WSGIScriptAlias /na ${APP_ROOT_DIR}/wsgi.py
<Location /na>
WSGIProcessGroup portal
</Location>
......

Wiederholen Sie die Fehler in der Datei ‚httpd-error_log' unten kontinuierlich:

Extension modules: bson._cbson, pymongo._cmessage, cx_Oracle, pvectorc (total: 4)
Fatal Python error: _PyInterpreterState_DeleteExceptMain: not main interpreter
Python runtime state: initialized
Current thread 0x00007ff9d892d700 (most recent call first):
File "/opt/python-3.10.4/lib/python3.10/multiprocessing/popen_fork.py", line 66 in _launch
File "/opt/python-3.10.4/lib/python3.10/multiprocessing/popen_fork.py", line 19 in __init__
File "/opt/python-3.10.4/lib/python3.10/multiprocessing/context.py", line 277 in _Popen
File "/opt/python-3.10.4/lib/python3.10/multiprocessing/process.py", line 121 in start
File "/opt/python-3.10.4/lib/python3.10/multiprocessing/pool.py", line 326 in _repopulate_pool_static
File "/opt/python-3.10.4/lib/python3.10/multiprocessing/pool.py", line 337 in _maintain_pool
File "/opt/python-3.10.4/lib/python3.10/multiprocessing/pool.py", line 513 in _handle_workers
File "/opt/python-3.10.4/lib/python3.10/threading.py", line 946 in run
File "/opt/python-3.10.4/lib/python3.10/threading.py", line 1009 in _bootstrap_inner
File "/opt/python-3.10.4/lib/python3.10/threading.py", line 966 in _bootstrap


Lösung des Problems

Die Antwort von: https://githubhot.com/repo/GrahamDumpleton/mod_wsgi/issues/750

Der erste Änderungsvorschlag besteht darin, anstelle von:

WSGIDaemonProcess ${url} user=${project-user} group=${project-group} python-path=${RootPath}/web/${url}/ python-home=${RootPath}/web/envs/${venv} display-name=${project} processes=3 threads=100 request-timeout=600
WSGIProcessGroup ${url}
WSGIScriptAlias / ${RootPath}/web/${url}/${app}/wsgi.py process-group=${url}

benutzen:

WSGIDaemonProcess ${url} user=${project-user} group=${project-group} python-path=${RootPath}/web/${url}/ python-home=${RootPath}/web/envs/${venv} display-name=${project} processes=3 threads=10 request-timeout=600
WSGIScriptAlias / ${RootPath}/web/${url}/${app}/wsgi.py process-group=${url} application-group=%{GLOBAL}

Fügen Sie außerdem außerhalb aller VirtualHost-Konfigurationen Folgendes hinzu:

WSGIRestrictEmbedded On

Dadurch wird verhindert, dass Python in untergeordneten Apache-Prozessen initialisiert wird, in denen es nicht verwendet wird.

In Bezug auf mod_wsgi-express können Sie etwas lernen, indem Sie sich ansehen, wie es konfiguriert ist, da es so eingestellt wurde, dass es gut für Python-WSGI-Anwendungen unter Apache funktioniert. Schlagen Sie vor, falls Sie es noch nicht getan haben:

https://www.youtube.com/watch?v=H6Q3l11fjU0

Keine Kommentare:

Kommentar veröffentlichen

Warum werden SCHED_FIFO-Threads derselben physischen CPU zugewiesen, obwohl CPUs im Leerlauf verfügbar sind?

Lösung des Problems Wenn ich das richtig verstehe, versuchen Sie, SCHED_FIFO mit aktiviertem Hyperthreading ("HT") zu verwenden, ...