# Dreamhost Application Errors

**URL:** <https://www.ruby-forum.com/t/dreamhost-application-errors/104025>\
**Category:** Radiant CMS\
**Created:** [May 13, 2007, 3:08am UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025 "2007-05-13T03:08:41Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [May 13, 2007, 3:08am UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/1 "2007-05-13T03:08:41Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [May 13, 2007, 5:03pm UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/2 "2007-05-13T17:03:47Z")

</div>

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](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/](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](http://domain.com/public) (Change [domain.com](http://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/](http://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](http://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/](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/](http://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](http://BladedThoth.com)

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [May 13, 2007, 7:27pm UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/3 "2007-05-13T19:27:58Z")

</div>

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](http://casperfabricius.com)

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [May 13, 2007, 5:15pm UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/4 "2007-05-13T17:15:47Z")

</div>

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](http://BladedThoth.com)

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [September 18, 2007, 3:35am UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/5 "2007-09-18T03:35:33Z")

</div>

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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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://mergulhao.info)  
[http://www.euemeu.com](http://www.euemeu.com)

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [September 18, 2007, 3:38am UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/6 "2007-09-18T03:38:38Z")

</div>

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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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://mergulhao.info)  
[http://www.euemeu.com](http://www.euemeu.com)

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [September 18, 2007, 6:03am UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/7 "2007-09-18T06:03:49Z")

</div>

> 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

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.

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [September 18, 2007, 8:03am UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/8 "2007-09-18T08:03:59Z")

</div>

On 9/18/07, Daniel S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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://mergulhao.info)  
[http://www.euemeu.com](http://www.euemeu.com)

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [September 18, 2007, 6:10pm UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/9 "2007-09-18T18:10:49Z")

</div>

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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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://mergulhao.info)  
[http://www.euemeu.com](http://www.euemeu.com)

---

<div class="post-metadata">

**Author:** ![tysone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tysone](https://www.ruby-forum.com/u/tysone)\
**Post date:** [September 18, 2007, 9:07am UTC](https://www.ruby-forum.com/t/dreamhost-application-errors/104025/10 "2007-09-18T09:07:05Z")

</div>

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.