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 126.96.36.199] 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:
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:
this assumes that’s you are using rails directly from svn already.