Things started to go downlhill when I had to check back on a previous article I had written about (Allowing full access to a sub directory in Apache Server) and my server would just hang!
Well, not a problem, let’s just try to hit the refresh key, hmmm, nothing. Ok, for good measure, let’s hit the button, just to be sure. Hmmm, still nothing.
Ok, let’s check out the logs, started from the apache logs.

[Tue Mar 28 21:04:31 2006] [error] [client 66.249.66.226] FastCGI: incomplete headers
(0 bytes) received from server “/home/psq/blog.nanorails.com/current/public/dispatch.fcgi”

Ok, yep, something’s wrong. Next, let’s hit the production.log. Nothing useful.

Next, a trick I learned before (aren’t you glad it is not your first time troubleshooting FastCGI?). Let’s call public/dispatch.fcgi directly:

/usr/local/lib/site_ruby/1.8/rubygems.rb:194:in `report_activate_error’:
    RubyGem version error: activerecord(1.13.2 not = 1.14.0) (Gem::LoadError)
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:136:in `activate’
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:162:in `activate’
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:161:in `each’
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:161:in `activate’
    from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:23:in `require’
    from ./../config/boot.rb:14
    from ./../config/environment.rb:8:in `require’
    from ./../config/environment.rb:8
    from ./dispatch.fcgi:21:in `require’
    from ./dispatch.fcgi:21

Ah ha! Bingo. What does it all mean, though?

It has been hard to miss that Rails 1.1 is not officially out. Yeahh!!! I wonder whether Dreamhost (aff) has maybe, just maybe, decided to upgrade.

gem list|grep rails

Ah ha! again. Yes, rails is is now 1.0 and 1.1. So I futz a little bit to try to freeze the gems manually, to not avail :(. So I go home, and fortunately, thanks to Capistrano, I have a full copy on my home machine! After doing a little reading, I figure the solution has to be:

rake freeze_gems

So first things first, I get home, rush to my machine, run the magic command, then run what was going to solve all the recent woes:

cap deploy -q

and hit the refresh button…
Duh! Still doesn’t work. Major Bummer!

Next step is to get a copy of all my gems (for typo):

 cd vendor/rails
 gem unpack activerecord
 gem unpack activesupport
 gem unpack actionpack
 gem unpack actionmailer
 gem unpack actionwebservice
 mv activerecord-1.13.2/ rails/
 mv actionmailer-1.1.5/ actionmailer
 mv actionpack-1.11.2/ actionpack
 mv actionwebservice-1.0.0/ actionwebservice
 mv activerecord-1.13.2/ activerecord
 mv activesupport-1.2.5/ activesupport

Your versions may vary depending on your install.

Then, committed everything, and redeployed.

and Ta Da! everything’s now back to normal! Phew…

The moral of the story, it that wasn’t clear already is:

Do not rely on the gems installed on your shared host!
Make sure your freeze all your gems

And I can worry on my own time to upgrade to rails 1.1 in my production environmment.

Update about 2 hours later:
Assuming you can run rake (which I couldn’t because of some broken dependency), an other method to lock down to rails 1.0 is to use:
rake freeze_edgeREVISION=3303

this assumes that’s you are using rails directly from svn already.

Update about 18h later:
An other solution is to lock down the versions of the gems you use in environment.rb using what suggested on Ruby On Rails Wiki. Thank you, Miles Barr for the tip!