Update: After a week of pretty poor performance I theorized that Dreamhost was killing off my Passenger processes, despite the fact that I was only using ~200MB of my allotted 300MB of memory on my VPS. Sure enough, increasing my allotment to 400MB seems to have resolved my site’s problems. I am left to conclude that you shouldn’t even try this unless you are on a VPS and have requested sufficient memory.
Correction: You need sudo access for this to work. Rails 3.1.0rc4 requires rack 1.3.0 and Dreamhost only provides rack 1.2.1. Installing a newer rack in your local gem directory will not help as rack is loaded before config.ru is read, so the wrong version will have already loaded before passenger starts. From testing just now, the only command you need to run as sudo is sudo gem install rack -v 1.3.0
Yesterday I spent most of the day struggling with getting my new rails site (this site, in fact) working on Dreamhost. To save others who might be trying to do the same thing some time, I figured I would share my findings here.
In the end it turned out to not actually be that complicated, once I gave in and accepted the fact that it’s best to use the passenger and ruby installations that Dreamhost offers, even though I have (limited) sudo access on my account and am using rvm.
That means you have to use ruby 1.8.7. So if you, like me, were developing under 1.9.2 that means you may have to change some code for compatibility.
First, set up your domain on dreamhost to enable passenger. Just go into the Dreamhost panel and the Manage Domains tab, check the ‘Passenger’ checkbox, and ensure that ‘Web Directory’ ends in ‘/public’. You can very easily deploy via capistrano by setting ‘Web directory’ to end in ‘/current/public’. I won’t go into more detail about setting up capistrano here, but the Dreamhost wiki has more info if you are interested.
Next, deploy your code to the location you specified above. The /public directory inside your rails root should match what you set ‘Web Directory’ to be, natch.
SSH into your Dreamhost, cd into your rails root, and bundle install. Set up rvm and be fancy about it, if that’s your bag. If you use rvm to set up a ruby gemset that is not MRI 1.8.7, then you will give yourself problems as passenger is still going to use 1.8.7 no matter what you say.
Now that you have passenger set up, your codebase in place, and all your needed gems installed, all you should need to do is tell passenger where to find said gems. To do this, edit your config.ru file in your rails root so it looks something like this:
ENV['GEM_HOME']="/PATH/TO/HOME/.rvm/gems/ruby-1.8.7-p334@GEMSET"
ENV['GEM_PATH']="#{ENV['GEM_HOME']}:/usr/lib/ruby/gems/1.8"
require 'rubygems'
require ::File.expand_path('../config/environment', __FILE__)
Gem.clear_paths
run YourApp::Application
This basically just tells passenger to look for gems in your home directory/rvm gemset before looking in the system gem directories. The order of those lines is rather important. The Gem.clear_paths is exceptionally important.
After that, touch tmp/restart.txt and see if passenger complains in the browser. If it does, the logs saying what the actual problem was might not wind up in either your rails logs or the virtualhost specific apache logs dreamhost provides in your home directory. In my case, they were in /dh/apache2/logs/apache2-psXXXXX/error.log, the log for my VPS. If you don’t have sudo access you probably won’t even be able to look at that file.
If everything worked, then yay- you’re done.
Unless of course you want to run WordPress within your rails install, like I am. If so, add the following to the .htaccess file in your wordpress directory:
PassengerEnabled off
And restart Passenger.
If you copied or moved wordpress from another location and are using the wp-cache plugin, make sure you clean up the cache or wordpress might get confused and serve only blank pages.
Further reading…
I hope that that someone finds this helpful. If so, you may also find these posts by other people helpful- they certainly helped me:
Problems?
Since some of the things DreamHost uses are rather old and the rails I am using is so new it’s not even really released yet, there are some problems.
- No Data Received Chrome periodically gives this error:
Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data. The log shows the pages as being served without error, though. If anyone has any ideas about this, I’d love to hear them.
- fcgid process manager died When this happens, Passenger restarts (slow):
mod_fcgid: fcgid process manager died, restarting the server I wonder if this is some Dreamhost thing automatically killing off these processes?
- backend application did not send a valid HTTP response When this happens, the rails view being generated will often trigger my 404 page:
file=ext/apache2/Hooks.cpp:684 : The backend application (process XXX) did not send a valid HTTP response; instead, it sent nothing at all. It is possible that it has crashed; please check whether there are crashing bugs in this application.
A lot of these problems seem very similar, but only one will occur at any time. I have a feeling that the error that shows up in the logs depends on where in the transaction whatever process is dying / getting killed ends.
Update: I believe these issues were caused by Dreamhost killing off my passenger processes for using too much memory. Increasing my memory allotment seems to have resolved them.
