Can't get fcgi working with Apache2 on Mac OS X


#1

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.


#2

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


#3

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 :slight_smile:

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

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

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

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


#4

On Jan 4, 2006, at 12:44 PM, Ross Ashley wrote:

each. But there’s more :slight_smile:

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.

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

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


#5

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 :slight_smile:

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


#6

Duane J. wrote:

On Jan 4, 2006, at 12:44 PM, Ross Ashley wrote:

each. But there’s more :slight_smile:

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 “

Application error

Rails application failed to
start properly”

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