Das deutsche Python-Forum

done: http://code.djangoproject.com/ticket/6610

Also irgendwie ist das alles nix mit fastCGI... Ich hab lokal einen Apache laufen und kann dort in die LOG Dateien schauen... Aber auch daraus wird man oft nicht schlau, wenn dort nur sowas auftaucht wie:

[Tue Feb 19 10:26:03 2008] [error] [client 127.0.0.1] (104)Connection reset by peer: FastCGI: comm with server "/home/jens/workspace/PyLucid_trunk/pylucid/index.fcgi" aborted: read failed, referer: http://localhost/
[Tue Feb 19 10:26:03 2008] [error] [client 127.0.0.1] Handler for fastcgi-script returned invalid result code 1, referer: http://localhost/

Hin und wieder tauchen dort ausgaben von stderr auf, das hilft dann schon mal weiter...

z.Z. hänge ich wein wenig fest. Ich möchte das eine Traceback-App nur einmal läuft, damit jede Änderung sofort aktiv ist, ohne das ich die Prozesse killen muss oder Apache einen Neustart braucht.

Ich hab mal eine kleine Test App gemacht:

Code: Alles auswählen

#!/usr/bin/env python2.4
# -*- coding: utf-8 -*-

import os, time
from flup.server.fcgi_fork import WSGIServer


start_overall = time.time()

def app(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    yield '<p>overall time: %.2fsec</p>\n' % (time.time() - start_overall)

    pid = os.getpid()
    yield '<p>pid: %s</p>\n' % pid


WSGIServer(
    app, maxRequests=1, maxSpare=1, maxChildren=1
).run()

Man kann sehen, das die pid pro Request eine andern Nummer ist. Denoch werden Änderungen im Sourcecode nicht direkt sichtbar. Das kann man auch an der Zeit sehen, die immer schön weiter läuft und nicht bei jedem Request von Null anfängt.

Ich bin wohl auf der Suche nach einer "auto-reload" Funktion für fastCGI, gibt es sowas?

Ich hab's, die Holzhammer Methode:

Code: Alles auswählen

#!/usr/bin/env python2.4
# -*- coding: utf-8 -*-

from flup.server.fcgi_fork import WSGIServer

import os, time

pid = os.getpid()
start_overall = time.time()

def app(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    yield '<p>overall time: %.2fsec</p>\n' % (time.time() - start_overall)

    global pid
    yield '<p>pid1: %s</p>\n' % pid

    yield '<p>pid2: %s</p>\n' % os.getpid()

    import signal
    os.kill(pid, signal.SIGHUP)

WSGIServer(
    app, maxRequests=1, maxSpare=1, maxChildren=1
).run()

Wenn man os.kill() auskommentiert kann man sehen, das der Hauptprozess immer der selbe ist, aber die App immer in einem neuen Prozess gestartet wird.
Würgt man den Hauptprozess ab, dann startet die App quasi nach jedem Request von neuem...

Kann man das so machen? Solle ich ein anderes Signal senden?

Unter Lighty werden bei mir FastCGI-Prozesse beim Server-Reload neu gestartet - sehr nützlich bisher.

Apache mus man restarten. Das dauert lange und man kann es nur mit root machen

Edit: Hm, mit os.kill() scheint Apache zusammen zu brechen...

Für Development gibt es daher ja auch den Development-Server. Eben deswegen.

Jo. Den nutzte ich ja auch. Aber ich hab anscheinend Probleme, die gerade bei fastCGI auftreten.

EDIT: Interessantes in den flup Quellentexten gefunden:

On most platforms, fcgi will fallback to regular CGI behavior if run in a
non-FastCGI context. If you want to force CGI behavior, set the environment
variable FCGI_FORCE_CGI to "Y" or "y".

Das ganze funktioniert aber so einfach nicht. Ich erhalten nur Fehlermeldungen wie diese hier:

2008-02-19 13:43:32,571 DEBUG WSGIServer: missing FastCGI param REQUEST_METHOD required by WSGI!
2008-02-19 13:43:32,571 DEBUG WSGIServer: missing FastCGI param SERVER_NAME required by WSGI!
2008-02-19 13:43:32,572 DEBUG WSGIServer: missing FastCGI param SERVER_PORT required by WSGI!
2008-02-19 13:43:32,572 DEBUG WSGIServer: missing FastCGI param SERVER_PROTOCOL required by WSGI!

Ein setzten der Variablen bringt es auch nicht.

In dem Zusammenhang ist das interessant:
http://groups.google.com/group/django-d ... 3070c66856

@Jens: ich hab Django auch mit FastCGI und Apache zum Laufen gekriegt. Aber Django hab ich normal in die site-packages installiert. Ich weiß nicht ob es so auch im Webspace laufen würde.

Es läuft bei mir mittlerweile auch per fastCGI. Aber es war ein steiniger Weg bis dahin. Ohne Zugriff auf die Apache Log ist das Debuggen recht schwer.

Ich weiß nicht wieso, aber irgendwie hab ich wohl auf Anhieb die richtigen Einstellungen gefunden.

Siehe http://www.python-forum.de/topic-13736.html

Bin mal gespannt, wann der Patch aus http://code.djangoproject.com/ticket/6687 aufgenommen wird. Das wäre hilfreich für alle, die keinen Einblick in die Apache Log hätten.

Das deutsche Python-Forum

django: fastCGI Probleme...