Produktiver WSGI-Server (Gunicorn) statt Flasks Entwicklungsserver
tesm.service startete die App bisher direkt per 'python3 app.py', was Flasks eingebauten Werkzeug-Entwicklungsserver nutzt -- der meldet bei jedem Start 'WARNING: This is a development server. Do not use it in a production deployment.' und ist bewusst nicht für Dauerbetrieb gebaut. Umgestellt auf Gunicorn, mit zwei bewusst gesetzten Einschraenkungen: - '--workers 1': die App haelt laufende Wartungs-Jobs/Import-Vorschauen nur im Arbeitsspeicher DES EINEN Prozesses (_maintenance_jobs, _pending_imports, ...) -- mehrere Worker-Prozesse wuerden diesen Zustand auf mehrere, sich nicht kennende Prozesse verteilen. - '--worker-class gthread --threads 16' statt eines async-Workers: das Browser-SSH-Terminal (flask-sock) belegt pro offener WebSocket- Verbindung einen blockierenden Thread. - '--timeout 0': deaktiviert Gunicorns eigenen 30s-Worker-Timeout, der sonst auch eine offene, aber gerade inaktive SSH-Terminal-Verbindung killen wuerde. Live auf POETEST verifiziert: keine WARNING-Zeile mehr, genau 1 Master- + 1 Worker-Prozess, alle Kernseiten weiterhin 200, und als kritischer Regressionstest das WebSocket-SSH-Terminal Ende-zu-Ende gegen einen echten Host erfolgreich getestet (Host-Key/Passwort-Prompt/Login/Shell). Dabei einen unabhaengigen Altlast-Fehler in POETESTs venv gefunden und allgemein in install.sh gefixt: './venv/bin/pip' hat eine zur Venv-Erstellung fest einprogrammierte Shebang-Zeile -- nach der historischen Umbenennung 'poe_manager' -> 'tesm' zeigte sie auf einen nicht mehr existierenden Pfad und schlug mit 'cannot execute: required file not found' fehl. 'python3 -m pip' umgeht das, da nur der (korrekt referenzierte) venv-Python-Interpreter selbst gebraucht wird -- betrifft sonst auch jedes kuenftige In-Place-Update auf einem aehnlich gewachsenen Host.
This commit is contained in:
+1
-1
@@ -1 +1 @@
|
||||
1.0.1
|
||||
1.0.2
|
||||
|
||||
@@ -7,6 +7,7 @@ Flask==3.1.2
|
||||
Flask-Bcrypt==1.0.1
|
||||
Flask-Login==0.6.3
|
||||
Flask-Sock==0.7.0
|
||||
gunicorn==23.0.0
|
||||
itsdangerous==2.2.0
|
||||
Jinja2==3.1.6
|
||||
ldap3==2.9.1
|
||||
@@ -31,3 +32,15 @@ Werkzeug==3.1.3
|
||||
# ldap3 (reines Python, keine System-Bibliothek wie libldap nötig) für die
|
||||
# optionale Active-Directory/LDAP-Anmeldung (Systemeinstellungen → LDAP) —
|
||||
# Search+Bind gegen einen AD-Domain-Controller oder generischen LDAP-Server.
|
||||
#
|
||||
# gunicorn: produktiver WSGI-Server für tesm.service (siehe dort) statt
|
||||
# Flasks eigenem app.run()-Entwicklungsserver ("WARNING: This is a
|
||||
# development server..."). Läuft bewusst mit genau EINEM Worker-Prozess,
|
||||
# aber mehreren Threads (--worker-class gthread) -- mehrere Prozesse
|
||||
# würden den In-Memory-Zustand für laufende Wartungs-Jobs/Import-
|
||||
# Vorschauen (_maintenance_jobs/_pending_imports/...) auf mehrere,
|
||||
# voneinander isolierte Prozesse verteilen, wodurch eine Anfrage, die vom
|
||||
# jeweils ANDEREN Worker beantwortet wird, diesen Zustand nie sehen würde.
|
||||
# Mehrere Threads (statt eines async-Workers) sind nötig, weil das
|
||||
# Browser-SSH-Terminal (flask-sock) pro offener WebSocket-Verbindung einen
|
||||
# blockierenden Thread belegt.
|
||||
|
||||
Reference in New Issue
Block a user