Django on Dreamhost: incomplete headers

I’ve recently bought a hosting in Dreamhost. There were two reasons:

  1. It’s possible to run Django on it
  2. It’s cheap

It’s a shared hosting, where many sites are served from a single physical machine. Each machine probably serves as much sites as possible, where the hardware capacity is the limit. The Dreamhost servers are pretty busy. My server for instance:

[shasta]$ uptime
16:03:42 up 31 days, 13:59, 6 users, load average: 10.48, 9.74, 9.24

It’s not the processing power that is the bottleneck here, at least on “my” server. There’s usually about 40% of idle processor time. However, when I ran tail command, it would get killed every now and then. Strange. Perhaps there’s a “garbage process collector” running on the site, terminating non essential jobs here and there.

Well, I bought the hosting and moved my main site to Dreamhost. PHP software ― PhpBB and MediaWiki ― is working great. I decided to try running Django, so I developed a small application and installed it. I followed the instructions, voila, it worked. I was happy.

At least until the Django app would eventually stop responding. I clicked a link and the browser just waited for data. The data never came. I looked into the logs.

[Thu Nov 30 14:56:16 2006] [error] [client] FastCGI: comm with (dynamic) server “/home/automatthias/” aborted: (first read) idle timeout (120 sec)
[Thu Nov 30 14:56:16 2006] [error] [client] FastCGI: incomplete headers (0 bytes) received from server “/home/automatthias/”

Something was wrong. Django isn’t officially supported on Dreamhost, so I couldn’t submit a complaint to the support. I searched the Web and found out that some guys had similar problems. Some other guys hadn’t. Dreamhost has many servers, and I figure it’s got something do to with the load of each server and… perhaps killing “non-essential” processes.

After some more research, I have found out that it’s not only Django users who’ve been experiencing that. There were also Rails users! You need to know, that Rails are officially supported on Dreamhost. I got interested and read on. Dreamhost support responded to the affected Rails user:

Check with our support team and ask if our process monitor has been killing your processes. If you have a lot of processes hanging around that may be the case. We recently updated our process monitor to specifically handle dispatch.fcgi processes specially so that is probably not the problem but it’s worth asking.

“specifically handle dispatch.fcgi processes”? Aha!

Inspecting my processes with “ps -ef” revealed that there were several “django.fcgi” processes running. Some of them were zombie (defunct). If the “dispatch.fcgi” processes are specifically handled, why don’t I pretend to run them? So I’ve changed my setup a little bit: I renamed my “django.fcgi” file to “dispatch.fcgi” and altered two lines in the “.htaccess” file, so they would refer to the new name:

RewriteRule ^(dispatch\.fcgi/.*)$ – [L]
RewriteRule ^(.*)$ dispatch.fcgi/$1 [L]

Guess what?

No timeouts, no 500s, no incomplete headers. It works like a charm.

Author: automatthias

You won't believe what a skeptic I am.

27 thoughts on “Django on Dreamhost: incomplete headers”

  1. Hey I heard dreamhost has frequent downtime lemme know how it goes. By the I added you to my blog roll I started to blog trying to add some people to my blog roll so it doesn’t look empty LOL 🙂

  2. I’ve been pulling out my hair for the last two weeks trying to solve this problem. I even pulled out the credit card today to register for a new host.

    Took a little while for the old processes to clear out of the way, but this seems to be working now.

    Thank you!

    Dreamhost support just told me the problem was with my script. But I knew I wasn’t the only one having this problem. And that it only started two weeks ago.

    Thanks again!

  3. I still get all the same timeouts and 500 errors:

    [Sun Dec 03 20:14:55 2006] [error] [client …] FastCGI: comm with (dynamic) server “/home/…/…/dispatch.fcgi” aborted: (first read) idle timeout (120 sec)
    [Sun Dec 03 20:14:55 2006] [error] [client …] FastCGI: incomplete headers (0 bytes) received from server “/home/…/…/dispatch.fcgi”

  4. So it apparently doesn’t work for everyone. Or, for every server. Each Dreamhost server can have slightly different features. I think the incomplete headers happen if the script disappears without a trace. Perhaps your script dies from another reason than their “process monitors”. Or the process monitor on this particular machine doesn’t handle dispatch.fcgi process specifically.

  5. The rails on dreamhost wiki page ( says “Dreamhost regularly kills off sleeping processes with their watchdog. This will kill your dispatch.fcgi processes, leading to Error 500s from time to time.” So it sounds like it’s not as simple as their watchdog script ignoring scripts named ‘dispatch.fcgi’. The page goes on to suggest a change to the dispatch.fcgi to make it ignore TERM signals but says that even that has mixed results with some users still having problems. I haven’t tried making the equivalent changes to the django dispatch.fcgi, but I tested a rails app on there and it seems to run just fine with no weirdness and *much* faster than django (which is pretty much the opposite of my experiences on any other machine).

  6. Using the flup fcgi stuff, I struggled to get our site going again for any length of time, even with the rename to “dispatch.fcgi”

    I’ve gone back to the pre-flup setup, without using any AddHandler in the .htaccess file. This got the site up and running right away, but at least once a day or so it’d go back down.

    So I have a cron script set to “killall -9 python” every 6 hours just to keep everything fresh. So far, so good. Is this a dangerous practice?

  7. Your cron script might kill a Python process while it’s processing a HTTP request, which would result in a 500 error. I don’t see any other dangers.

    As for the .htaccess file, mine contains only rewrite rules. I have initially copied the whole content of the example on the Dreamhost Wiki, but removed it at some point of my quest for a solution.

  8. I am having this problem on rails on dreamhost. Not cool… Debating switching back to colo since I thought dreamhost would make the installs easier… thus far installing trac has been a headache, subdomains have been a headache, and suddenly I am getting all these 500 errors… yup

  9. Pingback: Automatthias
  10. I have been through this incomplete headers problem and I spent too much time on it as well. The cause of my problems was memory limit on apache threads. Dreamhost staff changed that and since then it has worked. At first Dreamhost tried to blame my script for the problems!

  11. Remember also to comment .cgi if you have it:

    AddHandler fastcgi-script .fcgi
    #AddHandler cgi-script .cgi

  12. Hey,

    I’ve been getting the following errors off my WordPress blog and I have no idea how to solve them.

    [Thu Mar 6 13:17:04 2008] [error] [client] FastCGI: comm with (dynamic) server “/var/www/fcgi/php-cgi” aborted: (first read) idle timeout (30 sec)
    [Thu Mar 6 13:17:04 2008] [error] [client] FastCGI: incomplete headers (0 bytes) received from server “/var/www/fcgi/php-cgi”

    I’ve tried to follow a lot of what’s been written but can’t find any .htaccess and all my other files are .php. Any suggestions?

  13. Nice post. This helped! I didn’t quite get the .htaccess rules but i figured out how to kill the processes every so often.

  14. i figured out what my problem was(or rather my friend did)
    the file in my project folder somehow got deleted after getting an ftp error… lame
    figured i post just in case anyone else tried everything and couldnt find the problem….

  15. Online materials from the conference include entries on the Spectrum Blog and commentaries available on the Adventist Today website. ,

  16. Pingback: work at home
  17. I’m having this problem (Connection reset by peer: FastCGI / incomplete headers) on multiple sites on different hosts. Your solution didn’t work for me. Could I hire you to take a look at it? (see my email in the comments).

Comments are closed.