Rails - Jul 2006 - Troubleshooting tips for getting Apache/RailsApp/Dreamhost

Hi,

Background: I''m currently stuck getting my basic rails application 
working on dreamhost.  I have gone throught the doco.  Note that I can 
via my unix account run "ruby script/server" and get the application 
working via webbrick.  The problem I am having is that trying to go to 
the app via the normal apache approach my browser just sits and spins 
with nothing coming back.

Question: Are there any good trouble-shooting tips on how I can 
test/prove for myself where a potential problem may lie in terms of 
ensuring the dreamhost apache server is correctly picking up my config, 
and then triggering ruby appropriately and runnign my rails application 
(I''m not really sure how this works)

The key files from what I can gather are:
- .htaccess: So I''m guessing this is what the dreamhost apache server 
picks up on for configuration - I''ve made the recommended adjustments 
here to get redirects to (a) dispatch.fcgi script and
(b) make sure it''s executable
- the "dispatch.fcgi" script

Just understanding how key flow concepts of a URL request coming into my 
dreamhost domain and how it triggers things would be great, and then 
pointers on how to faultfind/monitor things to try to find out at which 
points things are working properly.

Thanks in advance

-- 
Posted via http://www.ruby-forum.com/.

You''re on the right track, in that those are the most likely things  
to try.

But here are lots of others.  Really triple check your config files,  
as small typos, line ending differences, or even extra returns (in  
YAML) could be causing the problem.

http://wiki.dreamhost.com/index.php/Ruby_on_Rails

            - dan
-- 
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>



On Jul 21, 2006, at 4:25 PM, Greg Hauptmann wrote:
> Hi,
>
> Background: I''m currently stuck getting my basic rails application
> working on dreamhost.  I have gone throught the doco.  Note that I can
> via my unix account run "ruby script/server" and get the
application
> working via webbrick.  The problem I am having is that trying to go to
> the app via the normal apache approach my browser just sits and spins
> with nothing coming back.
>
> Question: Are there any good trouble-shooting tips on how I can
> test/prove for myself where a potential problem may lie in terms of
> ensuring the dreamhost apache server is correctly picking up my  
> config,
> and then triggering ruby appropriately and runnign my rails  
> application
> (I''m not really sure how this works)
>
> The key files from what I can gather are:
> - .htaccess: So I''m guessing this is what the dreamhost apache
server
> picks up on for configuration - I''ve made the recommended
adjustments
> here to get redirects to (a) dispatch.fcgi script and
> (b) make sure it''s executable
> - the "dispatch.fcgi" script
>
> Just understanding how key flow concepts of a URL request coming  
> into my
> dreamhost domain and how it triggers things would be great, and then
> pointers on how to faultfind/monitor things to try to find out at  
> which
> points things are working properly.
>
> Thanks in advance
>
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Tks Dan - I''ll double check these things.

I was really hoping to learn more about how to do more "white box" 
fault-finding rather than keep trying things until the system works.  My 
best guess is to start by reading up on how FastCGI is configured and 
works within Apache, and then how this passes requests or kicks ruby 
into gear when it needs to.  This might then give me leads on where the 
monitor points might be for things like (a) did the request get to 
apache, (b) did apache pass it in to FastCGI, (c) did FastCGI try to 
engage Ruby etc, if this makes sense.

Any leads/ideas on what some good monitoring points are here from anyone 
would be great, or suggestions on what I shoudl be reading up on to 
learn how this this stuff works for myself.

thanks & cheers
Greg


Dan Kohn wrote:
> You''re on the right track, in that those are the most likely
things
> to try.
> 
> But here are lots of others.  Really triple check your config files,
> as small typos, line ending differences, or even extra returns (in
> YAML) could be causing the problem.
> 
> http://wiki.dreamhost.com/index.php/Ruby_on_Rails
> 
>             - dan
> --
> Dan Kohn <mailto:dan@dankohn.com>
> <http://www.dankohn.com/>  <tel:+1-415-233-1000>

-- 
Posted via http://www.ruby-forum.com/.

Greg Hauptmann wrote:
> ...(a) did the request get to 
> apache, (b) did apache pass it in to FastCGI, (c) did FastCGI try to 
> engage Ruby etc, if this makes sense.
> 
> Any leads/ideas on what some good monitoring points are here from anyone 
> would be great, or suggestions on what I shoudl be reading up on to 
> learn how this this stuff works for myself.
a - look in the apache logs under ~/logs/site.name/http. If there are 
entries in error.log, apache at least tried to start your fcgi process

b - look in rails_app_dir/log/ in fastcgi.crash.log. If there are 
entries in there, apache started your fcgi process

c - look in rails_app_dir/log/ in production.log if there are entries in 
there, your rails app tried to do something.

Hope this helps!

--Al Evans

-- 
Posted via http://www.ruby-forum.com/.

On 7/22/06, Greg Hauptmann <gregsfm@tpg.com.au>
wrote:
> I was really hoping to learn more about how to do more "white
box"
> fault-finding rather than keep trying things until the system works.  My
> best guess is to start by reading up on how FastCGI is configured and
> works within Apache, and then how this passes requests or kicks ruby
> into gear when it needs to.  This might then give me leads on where the
> monitor points might be for things like (a) did the request get to
> apache, (b) did apache pass it in to FastCGI, (c) did FastCGI try to
> engage Ruby etc, if this makes sense.
>
> Any leads/ideas on what some good monitoring points are here from anyone
> would be great, or suggestions on what I shoudl be reading up on to
> learn how this this stuff works for myself.
The best way to monitor what apache is doing, aside from strace, is
its error log. Especially if you set LogLevel debug, though don''t
leave that on as your logs will grow quickly.

Which version of apache are you using? I''ve used mod_fcgid (not
mod_fastcgi) with apache 2.0 and 2.2 to good effect.

-- 
noodl

Did you enable FastCGI in the Dreamhost control panel?

https://panel.dreamhost.com/
then click Managed Domains
Web Hosting, edit

PHP Version:  5.1.2  4.4.2
Extra Web Security? (highly recommended)
FastCGI Support? (advanced)

-- 
Jon Smirl
jonsmirl@gmail.com

thanks Guys - excellent tips - I''ve got things working (see below)

Jon - re "Did you enable FastCGI in the Dreamhost control panel?"
==> Yep I did this for the subdomain I''m using for the app.  I did 
notice that my main domain itself I HAD NOT enabled FastCGI.  After I 
enable this on the parent domain as well this basically got things 
working  :)

Al - Thanks for the fault finding tips.  This was exactly what I was 
trying to find out.

Vincent - Actually I''m not exactly sure on Dreamhost how to confirm
what
version of apache is actually running.  Things like ps & top seemed to 
be locked down so you can only see your own processes.  :(    - but then 
again I''m only a novice re unix.  I can see there seems to be an apache
and a apache2 directory on the machine.


Just a point of interest I see under top there are 3 ruby processes 
running.  I''m guessing these might be 3 identical ruby interpretters 
ready to take a request that FastCGI pools?   Just guessing, I''ll have 
to read up on FastCGI and ruby and how this works.  I have already read 
about potential zombie processes associated with FastCGI that one has to 
kill off from time to time too.

Thanks again
Greg


-- 
Posted via http://www.ruby-forum.com/.