Rails - Jan 2006 - Can''t get fcgi working with Apache2 on Mac OS X

I have an application that works fine in development mode under plain 
old CGI and I''m trying to get it running under FCGI with multiple hours
of frustration. Lately, I am running dispatch.fcgi standalone from the 
command line. It gives me a not very helpful one line error message;

Status: 500 Internal Server Error

The log file produces a not very helpful 2 line message;

[02/Jan/2006:11:32:58 :: 10957] starting
[02/Jan/2006:11:32:59 :: 10957] terminated gracefully

How can I figure out what''s going on here?

Running dispatch.fcgi standalone like this should take Apache out of the 
equation completely shouldn''t it? If I can get the dispatcher working 
correctly, then I can move onto Apache config problems but I''m stuck
for
now.

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

Ross Ashley wrote:
> I have an application that works fine in development mode under plain 
> old CGI and I''m trying to get it running under FCGI with multiple
hours
> of frustration. Lately, I am running dispatch.fcgi standalone from the 
> command line. It gives me a not very helpful one line error message;
> 
> Status: 500 Internal Server Error
Unfortunatly, that''s expected behavior. dispatch.fcgi is expecting that
it''s going to have the FCGI protocol spoken to it and when it
doesn''t
see that, it spits back the 500 message.
> How can I figure out what''s going on here?
> 
> Running dispatch.fcgi standalone like this should take Apache out of the 
> equation completely shouldn''t it? If I can get the dispatcher
working
> correctly, then I can move onto Apache config problems but I''m
stuck for
> now.
When trying to debug a fastcgi problem under Apache 2, start up Apache 
and pay very close attention to both it''s error log and the FastCGI 
error log. Also, make sure that your RewriteRules are in place 
correctly. If you are putting them into the main Apache configuration 
file (as opposed to an .htaccess file), make sure that they are placed 
inside of a Directory block. If you have it in an .htaccess file, make 
sure that your server is reading and using it. Check your AllowOverrides 
directives and such. If you have all the software components correct, 
the big issue is probably in configuration. If you post yours, it might 
be helpful for others to take a look at.

I don''t have any other quick tips for you right off the bat. I do plan 
on cooking an example Apache configuration on my blog in the near 
future, but haven''t done so yet (if only I had more time!). I know that
doesn''t help as much as might be nice, but.... do know that Apache2 + 
FastCGI on MacOS X _can_ indeed work. I''ve got it up and running just 
fine. After hours of frustration to learn how.

Have you considered Lighty? I only ask as I''ve got that sample 
configuration already prepared and up.

http://duncandavidson.com/essay/2005/12/railsonlighty

James Duncan Davidson

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

Well, maybe fastcgi is working now (I get only informative stuff in the 
apache log and the fastcgi.crash.log) but I''m getting a weird 
recognition error in my production log;

ActionController::RoutingError (Recognition failed for 
"/images/FA_G2_08_L.jpg"):

There are 16 images in all and there''s a stack trace corresponding to 
each. But there''s more :-)

ActionController::RoutingError (Recognition failed for 
"/javascripts/change_image.js"):

with stack trace and...

ActionController::RoutingError (Recognition failed for 
"/stylesheets/display.css"):

etc.

So it looks like the subdirs from app_name/public are not getting found 
by the default routing rules. Is there something I''m missing here? The 
production database is working fine and indeed the app makes proper 
queries and gets proper results if the image above is being requested. I 
just thought of a possible reason for this. In my thrashing around for 
the past few days I installed Rails v1.0.1. I built my app under 
0.14.something. Surely, surely, that has nothing to do with it!!

James Duncan Davidson wrote:
> When trying to debug a fastcgi problem under Apache 2, start up Apache 
> and pay very close attention to both it''s error log and the
FastCGI
> error log. Also, make sure that your RewriteRules are in place 
> correctly. If you are putting them into the main Apache configuration 
> file (as opposed to an .htaccess file), make sure that they are placed 
> inside of a Directory block. If you have it in an .htaccess file, make 
> sure that your server is reading and using it. Check your AllowOverrides 
> directives and such. If you have all the software components correct, 
> the big issue is probably in configuration. If you post yours, it might 
> be helpful for others to take a look at.
I''m running Rails V1.0.0 with Ruby 1.8.3 and Apache v2.0.39 on Mac OS X
v10.3.9

Here are relevant sections of my config;

httpd.conf;

...
LoadModule fastcgi_module modules/mod_fastcgi.so

<IfModule mod_fastcgi.c>
    FastCgiIpcDir /tmp/fcgi_ipc
    FastCgiServer /usr/local/apache2/htdocs/mj/public/dispatch.fcgi \
        -initial-env RAILS_ENV=production \
	-processes 15 -idle-timeout 60
</IfModule>
...

and my virtual host setup;

<VirtualHost *:80>
  ServerName mj
  DocumentRoot /usr/local/apache2/htdocs/mj/public/
  ErrorLog /usr/local/apache2/htdocs/mj/log/apache.log

  <Directory /usr/local/apache2/htdocs/mj/public/>
    Options ExecCGI FollowSymLinks
#    AddHandler fastcgi-script fcg fcgi fpl
    AllowOverride all
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

My .htaccess file from public/ has the following top three lines from 
the default produced by running, in this case, ''rails mj''.

# General Apache options
AddHandler fastcgi-script .fcgi
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI

I then uncommented the RewriteRule for fastcgi..

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
RewriteEngine On
> Have you considered Lighty? I only ask as I''ve got that sample 
> configuration already prepared and up.
It might yet come to that but I have to figure the Recognition error out 
first.

--Ross

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

Ross Ashley wrote:
> Well, maybe fastcgi is working now (I get only informative stuff in the 
> apache log and the fastcgi.crash.log) but I''m getting a weird 
> recognition error in my production log;
> 
> ActionController::RoutingError (Recognition failed for 
> "/images/FA_G2_08_L.jpg"):
> 
> There are 16 images in all and there''s a stack trace corresponding
to
> each. But there''s more :-)
> 
> ActionController::RoutingError (Recognition failed for 
> "/javascripts/change_image.js"):
> 
> with stack trace and...
> 
> ActionController::RoutingError (Recognition failed for 
> "/stylesheets/display.css"):
> 
> etc.
> 
> So it looks like the subdirs from app_name/public are not getting found 
> by the default routing rules. Is there something I''m missing here?
The
> production database is working fine and indeed the app makes proper 
> queries and gets proper results if the image above is being requested. I 
> just thought of a possible reason for this. In my thrashing around for 
> the past few days I installed Rails v1.0.1. I built my app under 
> 0.14.something. Surely, surely, that has nothing to do with it!!
I rebuilt the app under my shiny new Rails v1.0.0 and I''m getting the 
exact same result. The app works fine under development mode and I get 
the Recognition errors under production mode. All I''m changing in the 
config files are the RewriteRule in .htaccess and the small IfModule 
section in the httpd.conf file (see previous post in this thread).

Is there some kind of default routing setup that needs to be present in 
production mode that is not documented anywhere on the web??!! I hardly 
believe it. What the heck is going on?

--Ross

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

On Jan 4, 2006, at 12:44 PM, Ross Ashley wrote:
> Ross Ashley wrote:
>> Well, maybe fastcgi is working now (I get only informative stuff  
>> in the
>> apache log and the fastcgi.crash.log) but I''m getting a weird
>> recognition error in my production log;
>>
>> ActionController::RoutingError (Recognition failed for
>> "/images/FA_G2_08_L.jpg"):
>>
>> There are 16 images in all and there''s a stack trace
corresponding to
>> each. But there''s more :-)
>>
>> ActionController::RoutingError (Recognition failed for
>> "/javascripts/change_image.js"):
>>
>> with stack trace and...
>>
>> ActionController::RoutingError (Recognition failed for
>> "/stylesheets/display.css"):
>>
>> etc.
>>
>> So it looks like the subdirs from app_name/public are not getting  
>> found
>> by the default routing rules. Is there something I''m missing
here?
>> The
>> production database is working fine and indeed the app makes proper
>> queries and gets proper results if the image above is being  
>> requested. I
>> just thought of a possible reason for this. In my thrashing around  
>> for
>> the past few days I installed Rails v1.0.1. I built my app under
>> 0.14.something. Surely, surely, that has nothing to do with it!!
>
> I rebuilt the app under my shiny new Rails v1.0.0 and I''m getting
the
> exact same result. The app works fine under development mode and I get
> the Recognition errors under production mode. All I''m changing in
the
> config files are the RewriteRule in .htaccess and the small IfModule
> section in the httpd.conf file (see previous post in this thread).
>
> Is there some kind of default routing setup that needs to be  
> present in
> production mode that is not documented anywhere on the web??!! I  
> hardly
> believe it. What the heck is going on?
It sounds like your rewrite rules aren''t working.  Normally, your  
rails app should never even see the request for resources in the  
public/ directory--the web server detects and handles those  
automatically first.

Check that your .htaccess file is being read by Apache, or that you  
have the corresponding rewrite rules in your main apache config.

Duane Johnson
(canadaduane)
http://blog.inquirylabs.com/

Duane Johnson wrote:
> On Jan 4, 2006, at 12:44 PM, Ross Ashley wrote:
> 
>>> each. But there''s more :-)
>>>
>>> 0.14.something. Surely, surely, that has nothing to do with it!!
>> hardly
>> believe it. What the heck is going on?
> 
> It sounds like your rewrite rules aren''t working.  Normally, your
> rails app should never even see the request for resources in the
> public/ directory--the web server detects and handles those
> automatically first.
That was the case. The .htaccess file sortof implies that if you just 
uncomment the fastcgi rewrite rule line, it will use that dispatcher but 
later in the file a cgi rewrite rule messes things up. Here is my 
.htaccess file that works correctly;

And thanks for your help.

# General Apache options
AddHandler fastcgi-script fcg fcgi fpl
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI

# If you don''t want Rails to look in certain directories,
# use the following rewrite rules so that Apache won''t rewrite certain 
requests
#
# Example:
#   RewriteCond %{REQUEST_URI} ^/notrails.*
#   RewriteRule .* - [L]

# Redirect all requests not available on the filesystem to Rails
# By default the cgi dispatcher is used which is very slow
#
# For better performance replace the dispatcher with the fastcgi one
#
# Example:
RewriteEngine On

# If your Rails application is accessed via an Alias directive,
# then you MUST also set the RewriteBase in this htaccess file.
#
# Example:
#   Alias /myrailsapp /path/to/myrailsapp/public
#   RewriteBase /myrailsapp

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

# In case Rails experiences terminal errors
# Instead of displaying this message you can supply a file here which 
will be rendered instead
#
# Example:
#   ErrorDocument 500 /500.html

ErrorDocument 500 "<h2>Application error</h2>Rails application
failed to
start properly"
> Duane Johnson
> (canadaduane)
> http://blog.inquirylabs.com/

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