RE: Dreamhost subscription?


#1

Dreamhost can be made stable. It’s easy to get around the 500 errors by
simply modifying the fcgi_handler code to ignore the TERM signals.

Here’s a sample dispatcher that will fix the 500 problems. Combine this
with the cron task that keeps your app alive and responsive and DH seems
to work a lot better.

#!/usr/bin/ruby

You may specify the path to the FastCGI crash log (a log of unhandled

exceptions which forced the FastCGI instance to exit, great for

debugging)

and the number of requests to process before running garbage

collection.

By default, the FastCGI crash log is RAILS_ROOT/log/fastcgi.crash.log

and the GC period is nil (turned off). A reasonable number of

requests

could range from 10-100 depending on the memory footprint of your app.

Example:

# Default log path, normal GC behavior.

RailsFCGIHandler.process!

# Default log path, 50 requests between GC.

RailsFCGIHandler.process! nil, 50

# Custom log path, normal GC behavior.

RailsFCGIHandler.process! ‘/var/log/myapp_fcgi_crash.log’

require File.dirname(FILE) + “/…/config/environment”
require ‘fcgi_handler’

class RailsFCGIHandler
SIGNALS = {
‘TERM’ => :exit_now,
}

def exit_now_handler(signal)
    dispatcher_log :info, "ignoring request to terminate 

immediately"
end
end

RailsFCGIHandler.process!

end of file

Brian H.
Web D.
Learning & Technology Services
Schofield 3-B
University of Wisconsin-Eau Claire
removed_email_address@domain.invalid


#2

I am trying to understand why this is necessary. I am on another shared
hosting company but I am seeing the same thing. The fastcgi log is
filled
with these:

[05/Mar/2006:00:34:59 :: 25968] asked to terminate immediately
[05/Mar/2006:00:34:59 :: 25968] terminated by explicit exit
[05/Mar/2006:00:40:36 :: 30458] starting

What is doing this? Does your fix address this? Are there any side
effects?

Thanks,

-Eric