Dreamhost Application Errors

I had great success with Radiant on a previous Web host, but switched
to Dreamhost for more robust hosting features.

Have been trying to get Radiant running with no luck. Haven’t found a
fix in various mailing list posts or the wikis.

Currently attempting to troubleshoot using dispatch.cgi versus
dispatch.fcgi (unsure why this is being returned @
http://www.tysonevans.com/cv ). dispatch.fcgi hangs and returns a
Rails application error.

When attempting to use dispatch.fcgi the error log file returns:

[error] FastCGI: comm with (dynamic) server
“/home/.pygmy/tysone/tysonweb/public/dispatch.fcgi” aborted: (first
read) idle timeout (60 sec)
[error] FastCGI: incomplete headers (0 bytes) received from server
“/home/.pygmy/tysone/tysonweb/public/dispatch.fcgi”

Running dispatch.fcgi or dispatch.cgi via SSH returns:

-bash: dispatch.cgi: line 3: syntax error near unexpected token (' -bash: dispatch.cgi: line 3: require File.dirname(FILE) +
“/…/config/environment” unless defined?(RAILS_ROOT)’

This is way beyond me… but I’d appreciate any tips on possible fixes.

Hello Tyson!

Welcome to DreamHost! (Heh.) DreamHost can be a challenge to get a
handle on. Here’s a few quick tips you really need to know.

Get Radiant running under dispatch.cgi. By doing this, you will know you
have Radiant working. When you do this, you will get more verbose errors
in the log as well, which you will find is a godsend.

Shell will become your friend. Make sure you know how to shell into
DreamHost

Make sure you have your rubygem install up and running. You will need
this. When you do get it up, make sure your .bash_profile has the
following in it based on where you installed your gems (I did it into
.gems so it’s not in my directory list all the time): (Here’s a link to
help you set it up http://wiki.dreamhost.com/RubyGems )

export PATH=“$HOME/bin:$PATH”
export RUBYLIB=“$HOME/local/lib/site_ruby/1.8”
export GEM_HOME=“$HOME/.gems”
export GEM_PATH=“/usr/lib/ruby/gems/1.8:$GEM_HOME”
export PATH=“$HOME/.gems/bin:$PATH”

This ensures that when you run ‘gem’ that it uses your local version,
and that --MOST-- (Not all, keep reading) applications uses your gems
first.

gem install radiant – That will get you the newest version, and ensure
your rubygem install is working under shell.

Now, a big issue with how they have apache set up is that it does not
regard your .bash_profile, .gemrc or otherwise when under FastCGI. This
being said, you have to make Apache recognize your Radiant gem install

Head into http://panel.dreamhost.com/ and go to Domains->Manage Domains.
Make sure you have your domain set up with the following settings:

Extra Web Security: Yes
FastCGI Support: Yes
Specify web directory: domain.com/public (Change domain.com to whatever
directory your web host will be in. Can’t)

While you’re in the panel, make sure you have a MySQL database up and
know the username/password.

Head into the shell and go into the domain.com/ folder (Or whatever you
called it - Don’t go into the public folder, if it is there.) Run the
following command:

radiant ./ --ruby=/usr/bin/ruby --database=mysql

This will generate the directories and get them up and running for you.
Radiant won’t be ready yet though. From here, head into config/ and edit
database.yml (pico works fine) You want to change the database,
username, password, AND add host: if it is not there, on both
development and production. In the host portion, you need to put
mysql.domain.com (It will be the first domain name you put with
dreamhost unless you’ve set up otherwise.) – They do not host the MySQL
database on the same system as the apache (Heck, your files aren’t even
technically on that server, they have those on a remote fileserver. All
your server is, is a process center for running Apache.)

Close that file, and edit environment.rb. Add these three lines to the
top of the file:

ENV[‘RADIANT_ROOT’] = ‘/home/myhome/.gems/gems/radiant-0.6.1’
ENV[‘GEM_HOME’] = ‘/home/myhome/.gems’
ENV[‘GEM_PATH’] = ‘/home/myhome/.gems:/usr/lib/ruby/gems/1.8’

myhome will be the same as your username you use to log into shell. If
you didn’t install rubygem to .gems, make sure you change that too.

Go down a few lines from there, and change the ENV[‘RAILS_ENV’] line to

ENV[‘RAILS_ENV’] ||= ‘production’

While development is fine for most other hosts, development seems to get
canned very often by DreamHost, so you might as well deal with the
little hassles linked to using ‘production’ - It’s not as bad to use on
dreamhost anyways; To restart apache in this instance, you would simply
touch dispatch.fcgi to restart Radiant(Apache) anyways.

Now, you may or may not have to tweak some of the rest of the
environment file. I can’t remember if you do.

Close and save that, and then head back to your main directory and head
into public folder. Add the following lines at the very bottom of the
file to help minimize 500 errors caused by DreamHost canning your
process mid-serving. There is a plug-in that apparently works really
well; I use it, but it hangs the whole thing up more than it saves from
500s.

class RailsFCGIHandler
private
def frao_handler(signal)
dispatcher_log :info, “asked to terminate immediately”
dispatcher_log :info, “frao handler working its magic!”
restart_handler(signal)
end
alias_method :exit_now_handler, :frao_handler
end

Also, make sure that the path to ruby got put in properly at the top:
#!/usr/bin/ruby

Make sure in your .htaccess in that folder that you have AddHandler
fastcgi-script .fcgi uncommented and that you changed the final
RewriteRule to

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

Now, one major thing you will need to do to help minimize DreamHost’s
automated process canner (Set at 200MB memory usage or appear ‘runaway’,
which is pretty loose term by them.) – You will need to make sure you
have any files hosted in your /public folder be under a RewriteCond
similar to this:

RewriteCond %{REQUEST_URI} ^/javasript/(.*)$

You need to do this for all your images, javascript files, favicon.ico,
and so forth. Any file that would be directly accessed by HTML, you need
it away from the Ruby on Rails dispatcher. If you don’t do that, you
will be having your memory constantly running up to and over 200MB,
causing dreamhost to can your process with no warning, forcing a lengthy
‘reboot’ of dispatch.fcgi, during which you will get an army of ‘500’
errors. An alternate route that I have chosen is by having a second host
to be home to my website files such as my images and such. This means
you only need to make enough RewriteCond’s to handle what is in place:
This is my current list of Rewrites for this purpose:

RewriteCond %{REQUEST_URI} ^/stats/(.)$ [OR]
RewriteCond %{REQUEST_URI} ^/javasript/(.
)$
RewriteCond %{REQUEST_URI} ^/favicon.ico$
RewriteCond %{REQUEST_URI} ^/images/(.)$
RewriteCond %{REQUEST_URI} ^/stylesheets/(.
)$
RewriteCond %{REQUEST_URI} ^/robots.txt$

You want to put this below RewriteBase /

DreamHost states they are Ruby on Rails-friendly, but their setup
doesn’t lend well to this. They have set up --5-- dynamic dispatch.fcgi
that will launch on your site, causing a plethora of issues; 200MB x 5
→ 1GB RAM. They will can everything of yours when it hits a certain
point, and if you have all 5 of your dispatchers flooded, rather than
your site going down temporarily until requests slow down (Like what
would happen with 2 static dispatchers.) Dreamhost will happily
continuously can your processes, INCLUDING shell processes until it is
happy you are no longer being a hog. This has happened to me twice. Not
pleasant. You’re essentially down until you have NO web traffic by this
point; Once took me over 5 hours and turning off the hosting temporarily
in the Panel. These ‘bursts’ in memory usage would be caused by Ruby on
Rails getting every single request for a file, even those that it
doesn’t control, and it having to handle them. If you put the
RewriteCond’s in place, it will simply allow Apache to handle them
itself rather than going through the dispatcher, leaving the dispatcher
to handle the issue itself.

Now, another thing to keep in mind; I don’t know if it is a Radiant or
DreamHost issue yet, but I’m getting ~2000 hits a day, and sometime
during that day, my cache gets bungled somehow and you’ll get an Apache
error, stating something to the effect that something happened. When
this happens, you need to go into http://www.domain.com/admin/pages/ and
click the ‘Clear Caches’ to fix this issue up. Sometimes you may need to
go into the shell and do a ‘touch dispatch.fcgi’ in the
domain.com/public/ folder to reset Apache. It is a nuisance for sure,
but it’s far less often than the 500 errors that you’ll get if you don’t
manage your .htaccess well.

Another tip: Unless you are hung badly, avoid using killall -9
dispatch.fcgi: Apache is set on a very long timer (5minutes+) for
timeout on the dispatchers, and you will be pulling your hair out trying
to figure out what Apache is not bringing the dispatchers back up.
Always use touch dispatch.fcgi unless that is not working; Touch will
work in most cases unless you have a major issue.

I hope I haven’t forgotten anything. This should get you up and running.
As mentioned before, I recommend running off of .cgi instead of .fcgi to
make sure it isn’t Radiant being a pain. Check the logs; They will tell
you a lot when you’re under .cgi. When you have all the above in place
(Some of above specifically pertains to dispatch.fcgi BTW.) give the
.fcgi a try.

I hope this helps. I wrote out the entire procedure I did for you and
others having issues. I know you likely know a good portion of this
already; A lot of these steps I had to come up with on my own.

Lemmie know if you need more help!
Andrew
BladedThoth.com

Hi Andrew,

I just have say: Brilliant tutorial. I’m not even trying to deploy
Radiant to Dreamhost, but I use them, and I know how many loopholes
and tricks you often need to get things running right at Dreamhost.
You should definitely add your tutorial to the Radiant Wiki so
everyone can benefit from it. Thanks for taking your time write this up.

Cheers,
Casper F.
casperfabricius.com

Hello all!

Okay, now that I have most of my other problems worked out, I’ve ran
into a new issue. It appears that after so long of being up and running,
I suddenly start receiving ‘Apache’ errors for certain pages of my site
(But not all.) Sometimes just 1 page, other times up to 10+. I try
restarting the dispatcher with touch. Tried killing the dispatchers.
Nothing worked. It seemed like something ‘stuck’ between instances. It
doesn’t affect any of the admin portion of Radiant at all, only specific
pages (And it is random as well.) It tends to happen to my currently
heavily-viewed pages most frequently, but isn’;t limited. (Chance of
failure seems directionally proportional to number of visits to the
page.) Using these ideas, I had the thought that there is a cache issue.
I headed into /admin/pages/ and cleared the cache. Eureka! Back up! Out
of the 10-12 times this has happened, this has worked every time. The
one time it didn’t, all I had to do was touch dispatch.fcgi and that
cleared it up.

Question: Why would viewing cached pages cause the cache a chance to
corrupt? Another question: Until this bug is worked out, is there a way
we can do a shell cronjob to manually clear the cache every so often
manually? During the day (and sleepytime too) I can’t babysit my site,
and it’d be nice to clear the cache through a cronjob once in a while to
make sure this issue hasn’t happened. I do suspect either Radiant or
Ruby on Rails is the culprit of this one, but not sure how to figure it
out.

As well, for those who may or may not have been following my previous
emails, I had a severe memory leak issue. I cured it by preventing
Radiant/Ruby on Rails from managing ANY server-side file requests
through the .htaccess. That killed most of my issues. The problem still
at hand however, is that my memory does slowly creep up still (Slower,
but still quiet noticable.) throughout the day. Any ideas what this
might be?

Thanks all again!
Andrew
BladedThoth.com

I’m getting the same problem(see below) with radiant 0.6.2 on
dreamhost… someone is getting something like this?

On 5/13/07, Andrew K. [email protected] wrote:

heavily-viewed pages most frequently, but isn’;t limited. (Chance of
failure seems directionally proportional to number of visits to the
page.) Using these ideas, I had the thought that there is a cache issue.
I headed into /admin/pages/ and cleared the cache. Eureka! Back up! Out
of the 10-12 times this has happened, this has worked every time. The
one time it didn’t, all I had to do was touch dispatch.fcgi and that
cleared it up.


Sylvestre Mergulhão - Free Software Development

http://mergulhao.info
http://www.euemeu.com

Here is the error log:

Processing SiteController#show_page (for 189.24.37.87 at 2007-09-17
18:17:02) [GET]
Parameters: {“action”=>“show_page”, “url”=>“/”, “controller”=>“site”}

NoMethodError (undefined method []' for false:FalseClass): /vendor/radiant/app/models/response_cache.rb:65:in read_metadata’
/vendor/radiant/app/models/response_cache.rb:71:in
response_cached?' /vendor/radiant/app/controllers/site_controller.rb:16:in show_page’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:1095:in
send' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:1095:in perform_action_without_filters’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:632:in
call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:638:in call_filter’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:438:in
call' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:637:in call_filter’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:638:in
call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:438:in call’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:637:in
call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:638:in call_filter’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:438:in
call' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:637:in call_filter’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:619:in
perform_action_without_benchmark' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in perform_action_without_rescue’
/usr/lib/ruby/1.8/benchmark.rb:293:in measure' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in perform_action_without_rescue’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/rescue.rb:83:in
perform_action' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:430:in send’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:430:in
process_without_filters' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:624:in process_without_session_management_support’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in
process_without_test' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in process’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:330:in
process' /vendor/radiant/vendor/rails/railties/lib/dispatcher.rb:41:in dispatch’
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:168:in
process_request' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:143:in process_each_request!’
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:109:in
with_signal_handler' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:142:in process_each_request!’
/usr/lib/ruby/1.8/fcgi.rb:600:in each_cgi' /usr/lib/ruby/1.8/fcgi.rb:597:in each’
/usr/lib/ruby/1.8/fcgi.rb:597:in each_cgi' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:141:in process_each_request!’
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:55:in
process!' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:25:in process!’
dispatch.fcgi:24

On 9/17/07, Sylvestre Mergulhão [email protected] wrote:

I’m getting the same problem(see below) with radiant 0.6.2 on
dreamhost… someone is getting something like this?


Sylvestre Mergulhão - Free Software Development

http://mergulhao.info
http://www.euemeu.com

NoMethodError (undefined method []' for false:FalseClass): /vendor/radiant/app/models/response_cache.rb:65:inread_metadata’
/vendor/radiant/app/models/response_cache.rb:71:in

Just checked in a change that will fix it from breaking your site.

Looks like either a process was falling over when writing out the
metadata or two processes were getting in each others way.

Do you have any other errors in your log file that look like
they show the errors in writing? If not, it’s probably just that
one process is trying to read the cache while another is writing
to it - my changes should stop that situation from erroring.

Dan.

On 9/18/07, Daniel S. [email protected] wrote:

Do you have any other errors in your log file that look like
they show the errors in writing? If not, it’s probably just that
one process is trying to read the cache while another is writing
to it - my changes should stop that situation from erroring.

Yeah, searching in the log, I found THE error. After this error, the
“index page” (/) doesn’t work anymore… only errors(like in the other
email) in the log.

THE error:

Processing SiteController#show_page (for 208.113.204.12 at 2007-09-13
12:00:03) [GET]
Parameters: {“action”=>“show_page”, “url”=>“/”,
“controller”=>“site”, “1189710003”=>nil}

SystemExit (exit):
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:116:in
exit' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:116:in exit_now_handler’
/vendor/radiant/vendor/rails/activerecord/lib/…/…/activesupport/lib/active_support/inflector.rb:250:in
to_proc' /vendor/radiant/app/models/response_cache.rb:169:in call’
/vendor/radiant/app/models/response_cache.rb:169:in cache_page' /vendor/radiant/app/models/response_cache.rb:169:in open’
/vendor/radiant/app/models/response_cache.rb:169:in cache_page' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:30:in benchmark’
/vendor/radiant/app/models/response_cache.rb:167:in cache_page' /vendor/radiant/app/models/response_cache.rb:146:in write_response’
/vendor/radiant/app/models/response_cache.rb:43:in cache_response' /vendor/radiant/app/controllers/site_controller.rb:39:in show_uncached_page’
/vendor/radiant/app/controllers/site_controller.rb:20:in show_page' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:1095:in send’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:1095:in
perform_action_without_filters' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:632:in call_filter’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:638:in
call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:438:in call’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:637:in
call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:638:in call_filter’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:438:in
call' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:637:in call_filter’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:638:in
call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:438:in call’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:637:in
call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:619:in perform_action_without_benchmark’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in
perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:293:in measure’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in
perform_action_without_rescue' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/rescue.rb:83:in perform_action’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:430:in
send' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:430:in process_without_filters’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:624:in
process_without_session_management_support' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in process_without_test’
/vendor/radiant/vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in
process' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:330:in process’
/vendor/radiant/vendor/rails/railties/lib/dispatcher.rb:41:in
dispatch' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:168:in process_request’
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:143:in
process_each_request!' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:109:in with_signal_handler’
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:142:in
process_each_request!' /usr/lib/ruby/1.8/fcgi.rb:600:in each_cgi’
/usr/lib/ruby/1.8/fcgi.rb:597:in each' /usr/lib/ruby/1.8/fcgi.rb:597:in each_cgi’
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:141:in
process_each_request!' /vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:55:in process!’
/vendor/radiant/vendor/rails/railties/lib/fcgi_handler.rb:25:in
`process!’
dispatch.fcgi:24


Sylvestre Mergulhão - Free Software Development

http://mergulhao.info
http://www.euemeu.com

Can It be a dreamhost problem? Dreamhost is knew to sometimes kill the
dispatchers… can this cause the problem?

On 9/18/07, Daniel S. [email protected] wrote:

That is a bit of a weird trace. I can’t quite follow how a trace
that looked like that could happen (I don’t see how the inflector
would want to get involved during the file opening process).


Sylvestre Mergulhão - Free Software Development

http://mergulhao.info
http://www.euemeu.com

That is a bit of a weird trace. I can’t quite follow how a trace
that looked like that could happen (I don’t see how the inflector
would want to get involved during the file opening process).

It’s falling over during the writing of the .yml file (line 169),
I’m guessing that’s due to multiple processes both trying to do
that writing. If you upgrade to current svn, you wont have the
problem with subsequent requests failing, but you might still
get the original error.

I’ll have a look at putting a rescue in that code to make sure
that if there’s any problem trying to write out the cache that
it just continues on without breaking the current request.