Snippet List
FastCGI handler in prefork mode first imports every application, then forks. If any application during import opens connection to database, open connection is inherited by all of child processes; open db connection cannot be shared between processes, and if one process sends a request, another can receive a reply; also, if one process closes it, others have a desynchronized database handle.
See:
* http://stackoverflow.com/questions/1573579/psycopg2-disconnects-from-server
* http://stackoverflow.com/questions/393637/django-fastcgi-randomly-raising-operationalerror
* http://code.djangoproject.com/ticket/13215
* http://groups.google.com/group/django-users/browse_thread/thread/2c7421cdb9b99e48
If you put this snippet in your project-level __init__.py, then running manage.py runfcgi will fail loudly if the database connection is open in the parent process. This will happen only when you provide debug=true option to runfcgi to avoid monkey-patching code that runs in production mode.
This is a basic view for a FastCGI authorizer against the Django auth. The idea is to return either a blank response with REMOTE_USER set on success, a forbidden response for failure, or a redirect to a login page when no user is logged in.
I use this view for a Trac instance running on the same (lighttpd) server as Django. lighttpd is set up to use Django as a FastCGI authorizer (using snippet 1149) for the Trac URLs instead of using basic/digest HTTP authentication, so Trac has the same users as Django.
- authenticate
- fcgi
- fastcgi
I use this as the FastCGI script for authorizers with lighttpd (though I guess it should work with little change on any other webserver supporting FastCGI). I point it to the same Django project/settings as the normal responder script.
As I use it to gate access to pages not served by Django, I can include those non-Django URLs in the main urls.py, connected to special authorizer view functions (in another snippet).
The two key parts of the script, compared to the equivalent one for Django in the normal FastCGI Responder role, are:
1. Pass the FCGI_AUTHORIZER as the role to WSGIServer
2. Generate a PATH_INFO variable from the REQUEST_URI (FastCGI authorizers aren't given PATH_INFO, but Django needs that to match against the URLconf.)
- authenticate
- fcgi
- fastcgi
This is a simple rc script, suitable for starting a FastCGI daemon on FreeBSD. Simply copy this into /usr/local/etc/rc.d , change all references to "signet" to the name of your app, mark it executable and modify /etc/rc.conf accordingly.
- fcgi
- freebsd
- fastcgi
- rc.d
- rc
Add fcgi to settings.INSTALLED_APPS then you can start and stop FCGI through manage.py
>python manage.py startfcgi
>python manage.py stopfcgi
In settings define runfcgi arguments using **FCGI_*** in settings
For example:
>FCGI_SOCKET='/var/tmp/project.sock'
>FCGI_PIDFILE='/var/run/project.pid'
One of **FCGI_SOCKET** or **FCGI_HOST**/**FCGI_PORT** will need to be defined, but if you forget they will error out.
**FCGI_PIDFILE** is required to be defined to allow the process to be terminated.
The solution is based on [dballanc's snippet](http://www.djangosnippets.org/snippets/420/).
Can easily be combined with any of the [SQL tracing solutions](http://www.djangosnippets.org/tags/debug/).
You might want to run a separate logging server and redirect your logs there. Please refer to the [logging reference manual](http://docs.python.org/lib/module-logging.html).
- log
- mod_python
- debug
- logging
- fcgi
7 snippets posted so far.