Rails, FCGI, DreamHost, and endless frustrations

Hi all!

I’m trying to deploy an application out to a subdomain at dreamhost. I
getting the dreaded “Rails application failed to start properly” error.
logs for my app are empty. In the DreamHost FTP app, when I look in the
error.log file (I’m guessing this the Apache error log file) I see the
following for each of my attempts:

[Sun Jul 16 12:36:32 2006] [error] [client] FastCGI:
comm with (dynamic) server
“/home/tdonaghe/flickr.icuo.us/flickr/public/dispatch.fcgi” aborted:
(first read) idle timeout (120 sec)
[Sun Jul 16 12:36:32 2006] [error] [client] FastCGI:
incomplete headers (0 bytes) received from server
[Sun Jul 16 12:44:13 2006] [error] [client] FastCGI:
comm with (dynamic) server
“/home/tdonaghe/flickr.icuo.us/flickr/public/dispatch.fcgi” aborted:
(first read) idle timeout (120 sec)
[Sun Jul 16 12:44:13 2006] [error] [client] FastCGI:
incomplete headers (0 bytes) received from server

From what I’ve seen in doing research, I think this indicates a problem with
FCGI. For some more background:

I have followed the instructions listed here:


This is a very simple non database app that I’ve tested on my local box
through a WebBrick server. I think that I’ve copied everything properly
set up the various config files properly. I editted the various files
shown in the tutorial above. I’ve done “chmod 755” to my public
and to the dispatch* files in there. My she-bang looks like this:


I’ve tried to kill FCGI various times using:

killall -USR1 dispatch.fcgi

when I try that I get this message:

dispatch.fcgi: no process killed

In another thread someone suggested doing this:

ps aux | grep dispatch

Which I did and nothing shows up for anything relating to dispatch. I’m
very familiar with Unix, but I’m guessing this means that FCGI is not
running? If so, how the heck do it up? Someone suggested using “touch”
dispatch.fcgi. That didn’t accomplish anything either…

I’ve looked at all of the Troubleshooting advice from Dreamhost and
elsewhere. I’m just at a loss.

I have mapped my subdomain as shown in the tutorial above. I’m pretty
at the complete end of things that I can think of or google about. Can
anyone please give me a few more tips or hints or anything that might
me get this up and running? I’m pretty darned frustrated.


When moving to FastCGI, I had to make sure I removed all the debug
from all the code. This will mess up the headers if the puts output goes
the wrong place.

Does that help?


Terry D. wrote:

I have mapped my subdomain as shown in the tutorial above. I’m pretty
at the complete end of things that I can think of or google about. Can
anyone please give me a few more tips or hints or anything that might
me get this up and running? I’m pretty darned frustrated.

Does log/fastcgi.crash.log have anything in it? If so, there’s some
problem in the application. If not, the dispatcher is never getting

–Al Evans

Hi Ian,

I think the fact that dispatch.fcgi never gets started means that none
the rails code has even been looked at by the system, right? From
everything that I’ve been doing so far, I’m pretty sure (though I could
wrong) that the problem is in the system not reading or starting or


Hi Al,

There is no log/fastcgi.crash.log file.

I’m pretty sure that the dispatcher is never getting started, but I
really know what that means or how to fix it.

I’ve deleted and recreated the project several times now doing EXACTLY
I did when I saw it almost work that one time. Since that one time,
the dispatch.fcgi file has never been read. I’ve made sure that
dispatch.fgci is identical to the file that I use in my trivial
application. Since it never gets started, I’m guessing that this
problem is
not caused by anything in my rails code, right? Because it seems that
of that even gets looked at until dispatch.fcgi gets kicked off.

Check your ruby path declaration in dispatch.fcgi. I’ve seen this type
error when this is not correct (invalid path to ruby).

Terry D. wrote:

Hi Al,

There is no log/fastcgi.crash.log file.

That seems to imply that dispatch.fcgi is never getting started.

I think somebody already suggested making sure that the hashbang line in
dispatch.fcgi matches what you see when you type “which ruby”.

The only other thing I can think of is: Are you sure you checked the box
for FastCGI support on the DH control panel, and set the “Web Directory”
to the path to your Rails public directory?

–Al Evans

Most common Dreamhost deployment errros:

  1. Dreamhost has switched some of the servers to Apache2… and Rails
    longer runs in Production mode by default. Set the environment to
    production by commenting out the appropriate line in
  2. Make sure you check USE FAST CGI when you create your domain in the
    Dreamhost panel
  3. Make sure that dispatch.fcgi has appropriate permissions… rwx
    775 works well for this file)
  4. Make sure that the first line of dispatch.fcgi is #!/usr/bin/ruby
  5. Make sure that .htaccess points to dispatch.fcgi and not
    dispatch.cgi(the default)
  6. Make sure you have frozen your gems so you don’t get beaten up when
    gets updated system-wide
  7. Errors with the format of the database.yml file

Finally, to avoid random 500 errors, you can replace your dispatch.fcgi
this one:


Hi all,

I actually figured out the problem!! Or at least I think I did. For
whatever reason, it seems that if I modify my config/environment.rb file
get this problem - the app times out and the logs report that
dispatch.fcgiwas never read. My little app uses the flickr gem which
depends on another
gem called xml-simple. I followed the instructions here:


I unpacked the gems into my vendor directory and inserted a line like:

ENV[‘GEM_PATH’] = File.expand_path(’~/.gems’) +

into the environment.rb file. After some experimentation with another
I discovered that no matter where I place this line in my
environment.rbfile I would get the can’t read
dispatch.fcgi error. I tried the other solution in the above link and
placed this line in the file:

config.load_paths += %W( #{RAILS_ROOT}/vendor/gem_name/lib )

substituting the proper values for gem_name for both of my gems. This
causes the same time out errors as well.

Finally, I removed all changes to the environment.rb file (except where
uncommented out the production line) and then copied the flickr.rb and
xmlsimple.rb files into my app/controllers directory. I restarted
dispatch.fcgi and everything works fine now!

My question now is, why does this happen, and is there another solution
should try so that I don’t have to copy these files out of my
vendor/gem_name directories? Maybe they need to be unpacked somewhere

Thanks for any illumination!


Did you try:

rake rails:freeze:gems # Lock this application to the current
gems (by unpacking them into vendor/rails)

This is the only safe way to deal with deployment because it
guarantees you’ll have the same gems on production as on development.

        - dan

Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000

Trry, sorry about that I missed that part about it not starting at all.
me the puts resulted in the errors

FastCGI: incomplete headers

but it looks like the other suggestions in this thread are probably
working through first. I have never used dreamhost and just had the
problems when going from windows to linux. The list posted by Brian seem
like a good start.


Well, I had to do the hack listed on that link just to get the flickr
Dreamhost doesn’t have the flickr gem.

I did this:

gemhome: /home//.gems

  • /home//.gems
  • /usr/lib/ruby/gems/1.8

But, no I didn’t do a

rake rails:freeze:gems

Would that help in this case?

Presumably, you have the flickr gem on your development machine to
get the code working. rake:freeze:gems copies that exact gem into
the vendor/rails directory (so that you can check it into your
version control). Then, when you do rake deploy, that exact gem will
be copied from your subversion repository to Dreamhost (still in the
vendor/rails directory). So, you never need to worry about Dreamhost
installing the gem on their own (or you installing it manually). I
believe it’s a much better solution than what Dreamhost recommends,
since you’re guaranteed that the gem on the server always matches the
one of your development machine. (Also note that Dreamhost provides
free Subversion, which you definitely need to be using as part of
your Capistrano deployment.)

        - dan

Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs