Site5 Nightmare

Rails
1

Hi all,

I’m absolutely tearing my hair out here… I’ve been fighting with a RoR
install on Site5 all afternoon.

First off, the app was running just fine, and is deployed via
capistrano. I
added page caching, a piston’d copy of Rails 1.2.2, and deployed. Ever
since
then, the server has been returning “Empty Requests” with no HTTP status
code, no response body, nothing. If you hit it with “curl -I
http://www.musicvilla.com/” you get nada. A web browser, it sits and
waits
for a minute, and then displays nothing.

I’ve tried running dispatch.fcgi from the command line, and I get the
correct error (400 Invalid Request), and the pre-requisite source for
the
default 500 error. So the dispatch.fcgi seems normal. The .htaccess file
is
the stock one that ships with Rails. All the shebangs are correct (this
app
was running fine until this morning when I re-deployed, so everything
should
be set up already.)

The fastcgi.crash.log files are empty (except when I run
dispatch.fcgimanually from the command line), and the
production.log file is empty as well. (I deleted them earlier for
testing)

I killed the copy of Rails, so it’s now running off of the 1.1.6 gem
version
of Rails installed on the server. I did that because I’m using ARMailer
and
it’s apparently not designed to work with non-gem versions of
ActiveMailer.
However, the problem persists.

I’ve noticed that when I run a web request, no FastCGI processes start
either (via ps ux).

I’m totally stumped.

If only I could use Mongrel on Site 5, my live would be SO MUCH BETTER.
Thank GOD for Planet Argon. I may be moving soon…

Anyway, does anyone have any clues? I’m just stumped.

–
Matt W.

Thermal Creative
http://blog.thermalcreative.com

2

On Feb 8, 2007, at 10:10 PM, Matt W. wrote:

testing)

I killed the copy of Rails, so it’s now running off of the 1.1.6
gem version of Rails installed on the server. I did that because
I’m using ARMailer and it’s apparently not designed to work with
non-gem versions of ActiveMailer. However, the problem persists.

I’ve noticed that when I run a web request, no FastCGI processes
start either (via ps ux).

I was having a very similar problem over the past few days. I emailed
Site5 support again this afternoon and they replied to say that they
couldn’t find anything wrong on the server end.

I tried chmod’ing log/fastcgi.crash.log to loosen up the permissions,
and that started to give me useful output. Once I cleaned up the
errors that revealed, the app started working.

James.

3

James,

Thanks for the info… I gave up for the night and rolled back to a
working
release. (Thank God for Capistrano…)

I’ll try your log suggestion tomorrow. Did you end up just setting 777
on
the log to actually get useful output?

Thanks!

Matt

On 2/8/07, James S. [email protected] wrote:

" you get nada. A web browser, it sits and waits for a minute, and then
production.log file is empty as well. (I deleted them earlier for testing)
I was having a very similar problem over the past few days. I emailed

–
Matt W.

Thermal Creative
http://blog.thermalcreative.com

4

On Feb 8, 2007, at 11:51 PM, Matt W. wrote:

Thanks for the info… I gave up for the night and rolled back to a
working release. (Thank God for Capistrano…)

I’ll try your log suggestion tomorrow. Did you end up just setting
777 on the log to actually get useful output?

666 works. I’d rather set it to 664, but I don’t have permission to
change the group.

James.

–
James S.
Play: http://james.anthropiccollective.org
Work: http://jystewart.net

5

Well, Site5 is blaming it on file/directory permissions. I’ve set 755
throughout the app (they recommended it, but it seems a bit extreme),
but it
still doesn’t work. Does anyone know of any good resources on correct
file
permissions with mod_fcgi-served apps? I feel like I’m shooting in the
dark,
and I don’t like that feeling :slight_smile:

Thanks!

Matt

On 2/9/07, James S. [email protected] wrote:

change the group.

–
Matt W.

Thermal Creative
http://blog.thermalcreative.com

6

Well, turns out the problem was a bit different… It’s related to
Capistrano setting g+w on deployed apps, which is a bad default if
you’re on
a shared host. To get around if you have to override the
:set_permissions
task in your own deploy.rb to prevent Capistrano from doing that.

I’ve got a blog post about it here:
http://blog.thermalcreative.com/articles/2007/2/9/site5-deployment-problems-with-latest-capistrano

Matt

On 2/9/07, Matt W. [email protected] wrote:

666 works. I’d rather set it to 664, but I don’t have permission to

–
Matt W.

Thermal Creative
http://blog.thermalcreative.com