Flask Waitress Serve Internal Error

[Karlirex]

Hallo,

ich habe eine fertig programmierte Web-Anwendung und diese für den Zugang von Außen (über eben die Rechner-IP) mit Waitress auf einer VM geserved.

Code: Alles auswählen

from Backend import db, app
from waitress import serve

if __name__ == '__main__':
    db.create_all()
    #app.run()
    serve(app, host="0.0.0.0", port=8080)

Das Probelm leider, ich bekomme bei einer speziellen Routen-Abfrage einen "Internal Error". Da sich die Waitress App nicht so gut debuggen lässt, habe ich das im normalen app.run() nochmal versucht nachzustellen. Ergebnis: keine Fehlermeldung.
Liegt es am Waitress? Okay auch nochmal vom normalen Rechner geserved. Ergebnis: keine Fehlermeldung.

Ich habe also local, Hauptrechner served keine Fehlermeldung, aber sobald ich es in der VM serve erhalte ich bei der Route eben einen "Internal Error".
Für mich nicht wirklich sinnvoll und greifbar, wo das Problem liegt.

Jemand vielleicht eine Idee?

Grüße
Karlirex

[__blackjack__]

@Karlirex: Das Problem ist nicht praktisch nachvollziebar beschrieben. Also man kann schon nachvollziehen, dass Du bei bestimmten Abfragen einen Internal Error bekommst, aber mit der Information kann man halt auch nicht mehr sagen als das da dann wohl irgendwo ein Fehler ist.

Was sagen denn die Server-Logs zu dem Internal Error? Da sollte dann ja stehen woran es scheitert.

[Karlirex]

Was genau meinst du mit Server-Logs? Bisher hab ich bei Waitress keine weiteren Error-Logs gesehen.
(Also zumindest steht im Terminal nichts, anders als bei dem app.run() bspw)

[noisefloor]

Hallo,

also lt. Doku hat waitress Logging aktiviert.

Hast du in der virtuellen Maschine alles installiert, was du auch auf dem lokalen Rechner hast? Stimmen die relativen Pfade auch auf dem virtuellen Rechner?

Frage, rein Interesse halber: warum hast du waitress gewählt und nicht was gängigeres wie z.B. gunicorn?

Gruß, noisefloor

[Karlirex]

Also zu dem Logging seh ich in der Konsole nicht wirklich etwas.
Zu der Frage mit dem waitress statt gunicorn, ich hatte bisher keine wirklichen Probleme mit waitress, dadurch, dass das wirklich ein eher kleiner Nutzerkreis etc. ist, reicht mir Performance etc. aus.

Ich habe den Fehler aber scheinbar gefunden, nur noch leider nicht ganz ausgemerzt.
Zunächst konnte man einen Filter auswählen, welcher keine valide Rückgabe enthielt (mein Fehler beim Programmieren) und anschließend und das ist gerade der "akute verbleibende" Fehler, läuft das Programm in einer VM mittels Aufgabenplanung. Lasse ich alles "händisch" offen kommt es zu keinem Fehler. Nehme ich die ausgeführte Aufgabenplanung kommt es beim erstellen eines Datenframes dann zum "Internal Error".

[noisefloor]

Hallo,

du kannst in so Fälle doch auch den Debugging-Modus deines Webframeworks in der VM aktivieren. Das sollte man zwar auf Produktivsystemen und Applikationen, die im öffentlichen Netz sind, nicht machen - aber so wie sich das anhört läuft das bei dir im Intranet mit kleinem Benutzerkreis - da ist das IMHO temporär ok, das zu aktivieren. Nur halt das Deaktiveren nach erfolgreicher Fehlerbehebdung nicht vergessen.

Zu der Frage mit dem waitress statt gunicorn, ich hatte bisher keine wirklichen Probleme mit waitress, dadurch, dass das wirklich ein eher kleiner Nutzerkreis etc. ist, reicht mir Performance etc. aus.

Ich nehme gunicorn primär, weil das IMHO alles sehr einfach zu konfigurieren ist - und man für alle gängigen Webframeworks Beispiele für gunicorn bekommt. Performance ist für mich sekundär, mir reichen zwei synchrone Worker locker aus.

Gruß, noisefloor

[Karlirex]

Naja der Witz ist ja, dass wenn ich es in der VM mit VSC laufen lasse, keine Fehlermeldung bekomme. (Egal, ob mit dem Flask app.run() oder waitress serve()) Erst wenn ich das ganze über die Aufgabenplanung und serve() laufen lasse, wirft es bei der einen Route den Internal. (Zu der Erkenntnis bin ich durchs ausprobieren dann gestern gekommen.)
Und da in der Aufgabenplanung keine Konsole/VSC aktiv offen ist, würde ich selbst beim Debug-Mode nichts sehen.

Die Aufgabenplanung läuft, damit a) ein Backup darüber erstellt wird und b) sollte die VM abstürzen jeder andere ITler nur die VM neustarten muss (so zumindest die ursprüngliche Idee, welche auch bei anderen Programmen gut funktioniert hat)

[sparrow]

Du bist der Entwickler der Anwendung. Also musst du auch dafür sorgen, dass Fehler geloggt werden. Entweder, indem das Programm das selber machst, oder du musst darauf hinweisen, dass man eine entsprechende Umgebung einrichten muss. Zum Beispiel durch Umleiten der Output-Streams.

Und offensichtlich verhält sich deine Anwendung anders, wenn sie nicht aus einer bestimmten Umgebung gestartet wird. Die Gründe können mannigfaltig sein. Rechteprobleme oder relative Pfade die falsch sind kommen da gerne mal vor.

Abstürzende VMs habe ich jetzt eher selten in einer produktiven Umgebung erlebt.

[Karlirex]

@sparrow: da gebe ich dir natürlich recht. Ich verstehe nur nicht so ganz, wie genau ich den Error loggen soll, wenn ich ihn in der normalen Entwicklungsumgebung nicht sehe, aber in der Production eben auftritt. was ich damit meine, an welcher Stelle müsste man da den Log einsetzen? Oder aktiviert man den Log an einer Stelle und er nimmt alles auf?
Das mit der VM und der daraus resultierenden Aufgabenplanung liegt an anderen Stellen begraben, sonst müsste man leider sämtliche Dienste bei den VMs von Hand alle x Wochen neustarten..

[noisefloor]

Hallo,

Und da in der Aufgabenplanung keine Konsole/VSC aktiv offen ist, würde ich selbst beim Debug-Mode nichts sehen.

Nee, das stimmt so nicht. Der Witz am Debugging Modes bei Webframeworks ist ja, dass du den Fehler als Webseite angezeigt bekommst. Für Flask siehe https://flask.palletsprojects.com/en/2.2.x/debugging/. Django macht das auch so und ich gehe mal davon aus, dass andere Webframeworks das auch machen / können.

Deswegen sollte man den Debugging Modus bei Anwendungen, die im Internet frei zugänglich sind, nicht aktivieren, weil man a) ggf. Interna über die Anwendung bekommt und b) ggf. einen Angriffsvektor gegen die Anwendung.

Gruß, noisefloor

[Karlirex]

@noisefloor: das ist korrekt und nutze ich bei der Entwicklung auch. Ich befürchte aber, zumindest findet sich dazu per Google nichts, nimmt waitress als Production-Server diese Funktion direkt raus und ich bekomme lediglich eine "Internal Server Error The server encountered an unexpected internal server error (generated by waitress)" angezeigt.
Ich habe mich nun einmal nach Logging umgeschaut und muss sagen, dass ich ganz nett, leider macht mir auch hier die Aufgabenplanung einen Strich durch.
Sobald ich mit den

Code: Alles auswählen

    from paste.translogger import TransLogger
    import logging

    accesslog = logging.basicConfig(filename='logs.log', level=logging.DEBUG)

    serve(TransLogger(app, setup_console_handler=False))

Zeilen das Logging aktiviere und anschließend den Dienst starten möchte, erhalte ich keine Verbindung mehr zur Serverseite. (ich bin also noch früher raus als ohne Logging).
Und wenn ich das ohne Aufgabenplanung starte, erhalte ich wie gesagt keinen Fehler und es wird auch keiner mitgeloggt.

Ich stehe also noch im Dunkeln, aber danke schonmal für eure Ideen und Zeit.

Grüße
Karlirex

[sparrow]

Dann solltest du herausfinden, was in der Umgebung, die die Aufabenplanung startet, anders ist. Hinweise habe ich dir ja schon gegeben.
Und wie gesagt: Du musst dich halt um das Logfing kümmern. Und wenn du die Aufgabenplanung verwenden willst, auch wissen, wie die funktioniert. Wo schreibt die ihre Logs hin? Wo leitest du den Output hin, etc.
Das sind Betriebssystemspezifika. Man muss sich mit einem Werkzeug auseindersetzen, wenn man es benutzen will.

[noisefloor]

Hallo,

Ich befürchte aber, zumindest findet sich dazu per Google nichts, nimmt waitress als Production-Server diese Funktion direkt raus

Ich mag mich irren, aber AFAIK generiert Flask im Debugging Modus eine HTML-Seite mit der detaillierten Fehlerbeschreibung und liefert die Seiten dann als Response zurück. Der Applikaitonsserver dazwischen hat damit nichts zu tun.

Konkret gefragt: hast das mal ausprobiert?

Kannst du deine Applikation auf dem V-Server mal ohne WSGI-Applikationsserver laufen lassen, direkt über den Dev-Server von Flask? Dann siehst du alle Fehler im Terminal. Ich gehe davon aus, dass du Zugriff auf den V-Server hast?

Auf welchem System läuft denn der Server? Wenn es ein Linux ist und du Waitress per systemd Service Unit startest kannst du auch mal schauen, ob was in den Logs von systemd auftaucht. Kannst du über journalctl abfragen.

Gruß, noisefloor