Sporadisch keinen Zugriff mehr auf CGIHTTPServer

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
absalom
User
Beiträge: 4
Registriert: Montag 30. Januar 2017, 22:52

Hallo,

auf dem Raspberry habe ich schon in einigen Projekten

Code: Alles auswählen

sudo python -m CGIHTTPServer 80
ohne größere Probleme verwendet. Nun erlebe ich im aktuellen Projekt, dass CGIHTTPServer die Nacht nicht überlebt. Soll heißen, dass - nachdem CGIHTTPServer Abends gestartet und getestet wurde - am Morgen kein Zugriff mehr vom Browser möglich ist. Es gibt einfach keine Antwort. Dabei ist der Raspberry3 weiterhin via Putty/Filezilla erreichbar. Der entsprechende Python (v2.7) Prozess läuft noch und netstat zeigt mir an, dass Python auf Port 80 lauscht.

Hat jemand eine Idee, wie ich den Fehler eingrenzen kann? (wobei ich Python Neuling bin)

Vielen Dank!
absalom
BlackJack

@absalom: Erst einmal die etwas ängstliche Frage: Bist Du wahnsinnig einen Webserver als Root laufen zu lassen‽ Dazu noch einen der nicht für den produktiven Einsatz gedacht ist…

Was sagen denn die Logausgaben des Servers was er wann zuletzt gemacht hat? Dir ist klar, dass der singlethreaded ist, also immer nur eine Anfrage zur gleichen Zeit bearbeitet? Wenn also ein CGI-Skript hängt und nix mehr von sich gibt, wirst Du auch vom Webserver nix mehr zu hören bekommen.
absalom
User
Beiträge: 4
Registriert: Montag 30. Januar 2017, 22:52

BlackJack hat geschrieben:@absalom: Erst einmal die etwas ängstliche Frage: Bist Du wahnsinnig einen Webserver als Root laufen zu lassen‽ Dazu noch einen der nicht für den produktiven Einsatz gedacht ist…
Lass es mich so sagen, ohne mich über meinen Gesundheitsstatus auszulassen :K : Ich konnte den Webserver auf Port 80 nur als Root starten, als normaler Benutzer pi hat es nicht geklappt. Wenn du eine Idee hast, wie ich den Webserver als normaler Benutzer auf Port 80 verwenden kann wär ich sehr interessiert.
BlackJack hat geschrieben: Was sagen denn die Logausgaben des Servers was er wann zuletzt gemacht hat?

Code: Alles auswählen

192.168.178.32 - - [30/Jan/2017 23:36:15] "GET /cgi-bin/client?refresh HTTP/1.1" 200 -
****client 610552 started on 30.01.2017 23:36:15
    client 610552: REMOTE_ADDR: '192.168.178.32'
    client 610552: QUERY_STRING0: 'refresh'
    client 610552: send msg 'RID32 refresh'to msqidSender with id 0
    client 610552: 10 messages received
    client 610552: dynamic JS requested
----clients 610552 finished after 0.001 seconds
192.168.178.39 - - [31/Jan/2017 06:55:11] "GET / HTTP/1.1" 200 -
192.168.178.39 - - [31/Jan/2017 06:55:11] code 404, message File not found
192.168.178.39 - - [31/Jan/2017 06:55:11] "GET /favicon.ico HTTP/1.1" 404 -
192.168.178.39 - - [31/Jan/2017 06:55:40] code 404, message File not found
192.168.178.39 - - [31/Jan/2017 06:55:40] "GET /favicon.ico HTTP/1.1" 404 -
sh: 1: 1: Too many open files
Wobei die Zeilen mit client von meinem CGI script kommen. Der letzte Zugriff gestern Nacht hat noch funktioniert. Heute Morgen um 06:55 beschwert er sich dann, dass er keinen Zugriff auf die index.html hat. Eben habe ich den Webserver noch mal neu gestartet (natürlich immer im selben Verzeichnis) und da war der Zugriff auf die index.html kein Problem
BlackJack hat geschrieben:Dir ist klar, dass der singlethreaded ist, also immer nur eine Anfrage zur gleichen Zeit bearbeitet? Wenn also ein CGI-Skript hängt und nix mehr von sich gibt, wirst Du auch vom Webserver nix mehr zu hören bekommen.
Ja, fand ich aber bisher nicht sehr störend.
BlackJack

*Den* Webserver will man nicht auf Port 80 laufen lassen, denn auf Port 80 würde man einen echten Webserver erwarten der für den Produktivbetrieb gedacht ist. Was spricht gegen einen Apache oder Nginx? Die sind dafür ausgelegt und da haben sich die Programmierer auch um Sicherheit und Rechte/Benutzer und so weiter Gedanken gemacht.

Die letzte Zeile bei den Ausgaben sieht mir doch nach einem Hinweis aus. Offenbar ist dem System dort für einen Prozess die Anzahl der gleichzeitig offenen Dateihandles ausgegangen. Was normalerweise nicht passieren dürfte wenn man sauber programmiert und Dateien die man öffnet auch immer zeitnah wieder schliesst.
absalom
User
Beiträge: 4
Registriert: Montag 30. Januar 2017, 22:52

o.k. dann steige ich besser auf Apache um.

Vielen Dank für deine Unterstützung!
Benutzeravatar
DeaD_EyE
User
Beiträge: 1012
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Bist du dir sicher, dass du auf Apache umsteigen willst? Der Apache2 ist ein voll bestückter Kampfhubschrauber inkls. voller Bewaffnung. Was ich damit sagen will, vielleicht ist der Apache2 für deine Wahl das Falsche. Der Nginx ist schlanker. Es gibt noch weitere Webserver, die man sich mal ansehen sollte. Unter anderem wären das thttpd und Hawaitha.

http://uwsgi-docs.readthedocs.io/en/lat ... start.html
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
BlackJack

@DeaD_EyE: Apache ist aber auch die Standardlösung für einen Webserver unter Linux. Solange man keine speziellen Bedürfnisse hat ist das der einfachste Weg.
Benutzeravatar
Cronut
User
Beiträge: 34
Registriert: Sonntag 5. Februar 2017, 09:50
Wohnort: HRO, GER

Der Umstieg wird aber trotzdem nicht das Problem lösen, dass fährlässig mit Ressourcen umgegangen wird oder?
Kenne mich jetzt im Details nicht mit Apache, Nginx etc. aus oder gibt es da eine Art "automatische" Ressourcenverwaltung,
die ungenutze, offene Ressource nach einem bestimmten Zeitintervall schließt?
“Clean code always looks like it was written by someone who cares.” (Michael Feathers)
Check out: https://awesome-python.com/
BlackJack

@Cronut: Stimmt, das Problem wird damit nicht direkt angegangen. Indirekt vielleicht schon, denn ich vermute mal ganz stark das Apache nicht komplett aufhört zu reagieren wenn *ein* CGI-Aufruf zu viele Ressourcen verbraucht. Also zumindest das Symptom dürfte verschwinden. Kommt vielleicht auch darauf an ob der auf Threads oder auf Prozesse eingestellt ist.

Ich dachte aber auch das Problem einen Test-/Entwicklungsserver der ausdrücklich nicht für Produktiveinsatz gedacht ist, als root zu starten ist das *viel* grössere Problem, das man zuerst angehen sollte. :-)

Was auch noch sein kann, ist ein Fehler in CGIHTTPServer selbst. Dann würde der Umstieg das Problem auch lösen.
absalom
User
Beiträge: 4
Registriert: Montag 30. Januar 2017, 22:52

Apache werde ich nutzen, da ich es aus der Vergangenheit kenne.
Den ursprünglich Fehler im CGI script sollte man natürlich unabhängig von der Wahl des Servers beseitigen. Aber da ich strukturell etwas an dem Script geändert hatte, ist danach der Fehler nicht mehr aufgetaucht, sondern hat sich damit praktisch erledigt.
Benutzeravatar
Cronut
User
Beiträge: 34
Registriert: Sonntag 5. Februar 2017, 09:50
Wohnort: HRO, GER

Aus der Dokumentation nochmal:
https://docs.python.org/2/library/cgihttpserver.html hat geschrieben:Note that CGI scripts will be run with UID of user nobody, for security reasons. Problems with the CGI script will be translated to error 403.
Apache muss man meines Wissens ja auch als root starten, kurz danach wechselt aber die Instanz zum in der Config angegebenen User/Gruppe. Glaube, das hat irgendwas mit der Portbindung zu tun, kann aber auch veraltetes Wissen sein.
“Clean code always looks like it was written by someone who cares.” (Michael Feathers)
Check out: https://awesome-python.com/
Antworten