lighttpd + python

[ZSchneidi]

Hey Leute,

nach längerem rumprobieren hab ich meine Python + Bottle + lighttpd anwendung zum laufen gebracht.

Jetzt stelle ich aber fest, dass der lighttpd keinerlei änderungen an den Sourcen registriert.

Ich hatte ein paar änderungen vorgenommen und die seite neu aufgerufen nichts davon zu sehen.
Ich nach einigem hin und her mal die komplette docroot gelöscht den server neu gestartet. Der
meckerte nicht mal, dass das verzeichnis nicht mehr existiert. Ich rufe die seite wieder auf und siehe da
alles beim alten, da frage ich mich woher der server das jetzt holt ???

Ich teste im Chrome und Cache ist deaktiviert. Ich hab zusätzlich gerade noch im FireFox versucht, da
bekomm ich die seite auch problemlos angezeigt, obwohl ich die vor dem Löschen nicht mal aufgerufen hatte.

Also clientseitig wird das nicht gecached.
Ich finde nur keine wirklich antwort darauf, wie sich das ausschalten lässt, bzw. was das überhaupt ist.

Kenne das vom Apache bisher so nicht, sind halt meine ersten Gehversuche mit dem Lighty.

Nen Tip wäre echt toll.
Danke

[jens]

Wenn du was anders als CGI nimmst, läuft i.d.R. der Server Prozess erst einmal eine weile. Wenn du dann an den Sourcen was änderst, wird nicht automatisch ein reload gemacht.

Wie man ein neu laden veranlasst ist unterschiedlich. Wenn man den Webserver Prozess neu startet, sollte aber alle Änderungen sichtbar sein...

[ZSchneidi]

Das merkwürdige is nur, dass ich den Server zwischenzeitig jedes mal beendet hab.
Selbst jetzt nach stunden und mehrmaligen neu starten obwohl die docroot schon längst nicht mehr existiert
wird die ursprüngliche Seite immer noch ausgeliefert.

Ich lasse den Anwendung über fastcgi laufen. Falls das irgendwie von belangen ist.

[jens]

Dann ist irgendwo ein Cache aktiv?

[ZSchneidi]

Hmm ich hab mal den Socket gewechselt und mit dem neuen nimmt er dann auch Änderungen an.

Bin jetzt noch nicht so vertraut mit der Socket Thematik unter Unix, aber dem kann man Abhilfe schaffen.
Hatte jetzt nur nicht erwartet, dass da nen Zusammenhang besteht.

[deets]

sockets sind keine magischen Dinger. Da muss ein Python-Prozess hinter laufen. Was fuer Prozesse laufen denn, und was sagt netstat -l?

[noisefloor]

Hallo,

wie ist den Python an lighthttpd angebunden?

Gruß, noisefloor

[Leonidas]

Vermutlich via FastCGI und da laufen offenbar FastCGI-Prozesse die beim Restart des Servers nicht neu gestartet werden. Aber mir ist eh nicht ganz klar warum man Lighttpd nehmen will, damit hatte ich eigentlich immer mehr Probleme als mit anderen Webservern (Apache, nginx, Cherokee).

[ZSchneidi]

Der python prozess ist via Fastcgi angebunden und ich hatte eigentlich gedacht, dass der prozess beim beenden des Servers mit beendet wird.

netstat lieferte unter anderem diese zeilen

unix 2 [ ACC ] STREAM HÖRT 471626 /tmp/fcgi.sock-2
unix 2 [ ACC ] STREAM HÖRT 472098 /tmp/fcgi.sock-3
unix 2 [ ACC ] STREAM HÖRT 471620 /tmp/fcgi.sock-0
unix 2 [ ACC ] STREAM HÖRT 382066 /tmp/fastcgi.python.socket-0
unix 2 [ ACC ] STREAM HÖRT 471624 /tmp/fcgi.sock-1
unix 2 [ ACC ] STREAM HÖRT 1106292 /tmp/ecc.fcgi.sock-0
unix 2 [ ACC ] STREAM HÖRT 1106294 /tmp/ecc.fcgi.sock-1
unix 2 [ ACC ] STREAM HÖRT 1106296 /tmp/ecc.fcgi.sock-2
unix 2 [ ACC ] STREAM HÖRT 1106298 /tmp/ecc.fcgi.sock-3

ich hatte fcgi in ecc.fcgi umbenannt also scheinen tatsächlich noch prozesse zu laufen.

Warum lighttpd ?
Ich hatte in der Entwicklungsumgebung testweise mit Apache gearbeitet, ging recht einfach und lief auch gut.
Allerdings für nen recht leistungsschwaches Target system eignet der sich nicht mehr und viele sind auch der Meinung
dass der Apache da ungeeigneter ist als lighttpd.
Bei nginx hatte ich erstmal nicht weiter versucht das ans laufen zu kriegen weil ich häufiger Statements gelesen hatte, das die
Python-anbindung nicht so sauber gepflegt sein soll.

Da gibts n haufen Pros und Cons wir hatten uns jetzt hier auf lighttpd festgelegt.
Er ist tatsächlich nicht gerade einsteiger freundlich, aber solange er später seinen dienst zuverlässig verrichtet...

[BlackJack]

@ZSchneidi: Der Witz bei FastCGI ist ja gerade, dass es ein vom Webserver unabhängiger Prozess ist und damit noch nicht einmal auf dem gleichen Rechner laufen muss wie der Webserver. Demnach sollte es nicht verwundern, dass ein Neustarten des Webservers keine Auswirkungen auf den FastCGI-Prozess hat. Und wenn Du die Webanwendung über FastCGI anbindest ist doch auch die Qualität der direkten Python-Unterstützung im Webserver egal. FastCGI ist ein Protokoll das unabhängig von konkreten Webservern und Programmiersprachen definiert ist.

[deets]

Ich wuerde defenitiv zu NGINX raten. Eben weil er so einfach aufzusetzen und gleichzeitig resourcen-schonend ist. Die Python-Prozesse via proxy-forwarding anbinden, und zB mittels gunicorn verwalten.