CODEWITHSUNDEEP
pythondjangolighttpdfastcgi
The.Anti.9
The.Anti.9

Reputation: 44648

Django lighttpd FCGI error

I am trying to deploy my django app via lighttpd + fcgi, but when I run the fcgi script, it gives me an error

Here's the fcgi script itself:

#!/usr/bin/python2.6
import sys, os

# Add a custom Python path.
sys.path.insert(0, "/home/wite")

# Switch to the directory of your project. (Optional.)
os.chdir("/home/wite/dormcode")

# Set the DJANGO_SETTINGS_MODULE environment variable.
os.environ['DJANGO_SETTINGS_MODULE'] = "dormcode.settings"

from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")

When running the fcgi script with python, I get a 302 FOUND. When I try to go to the page via a web browser, I get nothing.

WSGIServer: missing FastCGI param REQUEST_METHOD required by WSGI!
WSGIServer: missing FastCGI param SERVER_NAME required by WSGI!
WSGIServer: missing FastCGI param SERVER_PORT required by WSGI!
WSGIServer: missing FastCGI param SERVER_PROTOCOL required by WSGI!
Status: 302 FOUND
Vary: Cookie
Content-Type: text/html; charset=utf-8
Location: http://localhost/login/
Set-Cookie:  csrftoken=30f07d4a59820a5ab7b502447cc16f5a; Max-Age=31449600; Path=/

*EDIT *

After playing around with some of the lighttpd configuration options, I managed to get something different. When I go to the app via the web browser, the page hangs for a while and turns up with a 500 Error, leaving this in the logs:

2011-02-12 01:04:59: (mod_fastcgi.c.2582) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: tcp:127.0.0.1:80 
2011-02-12 01:04:59: (mod_fastcgi.c.3367) response not received, request sent: 1076 on socket: tcp:127.0.0.1:80 for /dormcode.fcgi?, closing connection

Upvotes: 1

Views: 1990

Answers (2)

Crast
Crast

Reputation: 16316

There's more to this than meets the eye.

payne is correct in that this fastcgi listener is using stdin as its socket for communication.

However, this is just one of the ways to run a FastCGI responder. In fact, it's the incorrect way to run a responder for lighttpd, because lighttpd does not support talking to its responders via stdin.

The key lies in this line:

runfastcgi(method="threaded", daemonize="false")

This is the correct line for apache, but not the correct line for lighttpd. For lighttpd, you want something like this:

runfastcgi(method="prefork", daemonize="true", host="127.0.0.1", port="3033")

What this will do is run the fastcgi process instead on a host/port of your choosing, as a daemon which will fork to the background. Set daemonize="false" for debugging, or if using something like supervisord but most people generally want a daemon.

It should be noted that the entire script is not necessary if your script is as simple as the one you just pasted. You can instead just run the fastCGI responder through manage.py:

./manage.py runfcgi method=prefork host=127.0.0.1 port=3033 pidfile=/path/to/foo.pid

Now that you've (hopefully) got your FastCGI responder running, you want to do this in your lighttpd config:

"/mysite.fcgi" => (
    "main" => (
         "host" => "127.0.0.1",
         "port" => 3033,
          "check-local" => "disable",
    )
),

That is, whatever port you choose for your fastcgi responder, you need to point lighttpd there.

It should be noted that all of this is available in the Django FastCGI documentation but this documentation has lost much of its clarity through frequent edits and some amount of feature creep in an open source project.

Upvotes: 3

payne
payne

Reputation: 14177

First, with sh you're trying to run your script as a shell script, not a Python program. If you really want to run it as a python program, type python /home/wite/code/code.fcgi

Second, keep in mind that FastCGI apps run as deamons -- you still need a Web server to connect to the process you're starting here.

Finally, if you're trying to test this FastCGI program by hand: this isn't always helpful, because FastCGI uses a special protocol on stdin and stdout between the Web server and your application. (You could test CGI scripts this way because CGI was much simpler).

Upvotes: 1

Related Questions