# Troubleshooting tips for getting Apache/RailsApp/Dreamhost **URL:** \ **Category:** Rails\ **Created:** [July 22, 2006, 1:25am UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374 "2006-07-22T01:25:47Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [July 22, 2006, 1:25am UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374/1 "2006-07-22T01:25:47Z")
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 ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [July 22, 2006, 10:02am UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374/2 "2006-07-22T10:02:42Z")
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](http://wiki.dreamhost.com/index.php/Ruby_on_Rails) ``` - dan ``` – Dan K. [mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://www.dankohn.com/](http://www.dankohn.com/)tel:+1-415-233-1000 ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [July 22, 2006, 1:30pm UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374/3 "2006-07-22T13:30:18Z")
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 K. 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](http://wiki.dreamhost.com/index.php/Ruby_on_Rails) > > ``` > - dan > > ``` > > – > Dan K. [mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [http://www.dankohn.com/](http://www.dankohn.com/)tel:+1-415-233-1000 ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [July 22, 2006, 5:31pm UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374/4 "2006-07-22T17:31:19Z")
Greg H. wrote: > …(a) did the request get to > apache, (b) did apache pass it in to FastCGI, © 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 ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [July 22, 2006, 5:35pm UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374/5 "2006-07-22T17:35:42Z")
On 7/22/06, Greg H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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. ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [July 22, 2006, 5:57pm UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374/6 "2006-07-22T17:57:39Z")
Did you enable FastCGI in the Dreamhost control panel? [https://panel.dreamhost.com/](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) ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [July 22, 2006, 11:56pm UTC](https://www.ruby-forum.com/t/troubleshooting-tips-for-getting-apache-railsapp-dreamhost/99374/7 "2006-07-22T23:56:49Z")
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