Hi Everybody,
I’m down to my last straw. I’ve been trying to deploy my latest rails
project on Apache for about two weeks with limited success. I have a
lot of info, but still no clue what is causing my problem. I decided to
turn to the community for some help…
Basically, my site works fine with Apache and FastCGI most of the time,
but sometimes I get the “Rails Failed to Start Correctly” error. I know
what the problem is. It seems that although I tried to set apache to
use a static number of servers, it still creates more dynamically.
Here is a basic flow of what happens:
-
I restart the webserver. Running “ps -A” I can see that the right
number of dispatch.fcgi scripts are running as specified in my
httpd.conf so I think I’m good.
-
I start testing the website and intermittently runing my “ps -A”
command and low and behold I find that Apache is firing more
dispatch.fcgi scripts than I specified.
-
After a while they begin to die off and every once in a while rails
can’t start properly.
I’ve tried various numbers of dispatchers and I still have the same
problem. I’m pretty confident that if I can fix the number of
dispatchers, my problem will go away.
Here is what I have in my httpd.conf (directly after the AddModule
section):
FastCgiIpcDir /var/fcgi_ipc/
AddHandler fastcgi-script .fcgi
FastCgiServer /home/app1/public/dispatch.fcgi -idle-timeout 120
-initial-env RAILS_ENV=production -processes 4
FastCgiServer /home/app2/public/dispatch.fcgi -idle-timeout 120
-initial-env RAILS_ENV=production -processes 2
Note that I have two rails apps running on this server. As far as I can
tell, app2 is giving me no grief, but app1 is.
Does anyone have any ideas? I hate to bother, but I think I’ve taken
this issue about as far as I can on my own.
Thanks
Matt
Hi Matt,
I found this post:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003572.html
Which looks like your problem. A response (which I admit to not
understanding 
is here:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003573.html
I realise it;s not an exact match, but appears to point to something
around Apache starting dynamic processes when there’s some permission
problem on the static processes.
Does this help at all (you, or anyone else reading?)
A.
Alan F. wrote:
Hi Matt,
I found this post:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003572.html
Which looks like your problem. A response (which I admit to not
understanding is here:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003573.html
I realise it;s not an exact match, but appears to point to something
around Apache starting dynamic processes when there’s some permission
problem on the static processes.
Does this help at all (you, or anyone else reading?)
A.
Another thought is that Apache think the first 4 servers have died.
COuld this be related to the timeout ? Perhaps the second app takes
longer to respond than the first (or something?)
Alan
Alan F. wrote:
Hi Matt,
I found this post:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003572.html
Which looks like your problem. A response (which I admit to not
understanding is here:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003573.html
I realise it;s not an exact match, but appears to point to something
around Apache starting dynamic processes when there’s some permission
problem on the static processes.
Does this help at all (you, or anyone else reading?)
A.
Thanks for the help. It seems like a similar problem indeed. I tried
adding the user and group like in the first example you showed and
apachectl told me this:
[warn] FastCGI: there is no fastcgi wrapper set, user/group options are
ignored
Syntax OK
I also tried adding the Suexec user line to my vhost, and apache failed
to restart with:
Invalid command ‘SuexecUserGroup’, perhaps mis-spelled or defined by a
module not included in the server configuration
So unfortunately that didnt solve the problem. Perhaps it is headed
down the right path, I’ll continue in that direction.
Another thought is that Apache think the first 4 servers have died.
COuld this be related to the timeout ? Perhaps the second app takes
longer to respond than the first (or something?)
Alan
It is entirely possible the second app takes longer to respond.
Another thought is that Apache think the first 4 servers have died.
COuld this be related to the timeout ? Perhaps the second app takes
longer to respond than the first (or something?)
Alan
For the time being, I’m disabling the second app to narrow the field and
focus on the problematic app. I’m still having issues however…
You are probably restricted to Apache aren’t you?
Otherwise you could try using lighttpd, works very well for me.
Alan F. wrote:
Hi Matt,
I found this post:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003572.html
Which looks like your problem. A response (which I admit to not
understanding is here:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003573.html
I realise it;s not an exact match, but appears to point to something
around Apache starting dynamic processes when there’s some permission
problem on the static processes.
Does this help at all (you, or anyone else reading?)
A.
Also, I’m not getting the same errors in my apache logs as this guy.
Here is a little sample of what is in my error log:
[Wed Apr 5 12:21:30 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 23612)
[Wed Apr 5 12:21:33 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 24544)
[Wed Apr 5 12:21:36 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 25280)
[Wed Apr 5 12:21:39 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 25824)
[Wed Apr 5 12:21:42 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 26210)
[Wed Apr 5 12:21:45 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 26592)
[Wed Apr 5 12:21:48 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 27460)
[Wed Apr 5 12:21:51 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 28033)
[Wed Apr 5 12:21:54 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 29152)
[Wed Apr 5 12:26:47 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” (pid 29152) termination
signaled
[Wed Apr 5 12:26:50 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” (pid 29152) terminated by
calling exit with status ‘0’
[Wed Apr 5 12:31:49 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” (pid 28033) termination
signaled
[Wed Apr 5 12:31:49 2006] [warn] FastCGI: (dynamic) server
“/home/app1/public_html/beta/dispatch.fcgi” (pid 28033) terminated by
calling exit with status ‘0’
where /home/app1/public_html/beta/ is a symbolic link to
/home/app1/public/
I wonder if the symbolic link might have something to do with it?
On Wed, 2006-04-05 at 18:39 +0200, mgbaron wrote:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003573.html
Here is a little sample of what is in my error log:
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 26210)
signaled
where /home/app1/public_html/beta/ is a symbolic link to
/home/app1/public/
I wonder if the symbolic link might have something to do with it?
I had issues trying to use symbolic links and just told httpd.conf the
<Directory “/home/craig/th-db/public”>
allow from all
Options Indexes ExecCGI FollowSymLinks
ReWriteEngine On
which is the real directory and life got easier
but I do have this…
FastCgiIpcDir /tmp/fcgi_ipc/
AddHandler fastcgi-script .fcgi
FastCgiServer /home/craig/th-db/public/dispatch.fcgi -initial-env \
RAILS_ENV=production -processes 15 -idle-timeout 60
and I’ve been thinking that 15 processes seems like too many and I will
probably cut them down and the -idle-timeout seems too short for a web
application for local intranet
Craig
15 is a heck of a lot of initial FCGI processes. Try four. Or two. No,
as a matter of fact, start with one (the default). I’m pretty sure more
will start as needed. See how that works. Fifteen are going to need a
whole lotta RAM, incidentally, and unless this is an intranet app being
hit by a whole lot of people at once at a pretty large company, many of
those processes are just going to sit there and do nothing but
initialize themselves, eat RAM and quite possibly degrade your app’s
performance.
Just curious: what OS are you running on?
Craig W. wrote:
On Wed, 2006-04-05 at 18:39 +0200, mgbaron wrote:
http://www.fastcgi.com/archives/fastcgi-developers/2005-January/003573.html
Here is a little sample of what is in my error log:
“/home/app1/public_html/beta/dispatch.fcgi” started (pid 26210)
signaled
where /home/app1/public_html/beta/ is a symbolic link to
/home/app1/public/
I wonder if the symbolic link might have something to do with it?
I had issues trying to use symbolic links and just told httpd.conf the
<Directory “/home/craig/th-db/public”>
allow from all
Options Indexes ExecCGI FollowSymLinks
ReWriteEngine On
which is the real directory and life got easier
but I do have this…
FastCgiIpcDir /tmp/fcgi_ipc/
AddHandler fastcgi-script .fcgi
FastCgiServer /home/craig/th-db/public/dispatch.fcgi -initial-env \
RAILS_ENV=production -processes 15 -idle-timeout 60
and I’ve been thinking that 15 processes seems like too many and I will
probably cut them down and the -idle-timeout seems too short for a web
application for local intranet
Craig
I had issues trying to use symbolic links and just told httpd.conf the
Craig… Thanks a Ton. I switched the symbolic link out in favor of
using the correct DocumentRoot in the apache config. It doesn’t appear
to be spawning any more processes!
Hi Guys,
I had the exact same problem deploying Apache 1.3 w/ Fast CGI to OS X
server (10.4). I drove me nuts!
I wanted to know why this symlink thing caused the problem. I’ve done a
couple of quick tests and this is what I can figure:
if your app is in /users/ryan/rails/myapp/ and you symlink it to
/users/ryan/sites/myapp/ you have to define your FastCgiServer as the
path that apache will be serving. Keeping in mind my document root is
/users/ryan/sites/
I.e. I had my FastCgiServer looking at
/users/ryan/rails/myapp/public/dispatch.fcgi rather than the path Apache
is serving through the symlink
/users/ryan/sites/myapp/public/dispatch.fcgi.
Must be some type of lookup problem or anomoly or intentional behaviour.
Cheers.
Ryan A. wrote:
path that apache will be serving. Keeping in mind my document root is
/users/ryan/sites/
I.e. I had my FastCgiServer looking at
/users/ryan/rails/myapp/public/dispatch.fcgi rather than the path Apache
is serving through the symlink
/users/ryan/sites/myapp/public/dispatch.fcgi.
Must be some type of lookup problem or anomoly or intentional behaviour.
Have you checked the Apache directive Options FollowSymLinks?
–
Ray
This is CentOS 4.3
I thought 15 seemed like a very high number but I didn’t just grab it
from thin air…some wiki that I used somewhere must have had that
suggestion and I made a mental note to revisit down the road and of
course, the mental note got lost somewhere. This discussion was a kick
on the side of my head which did a db_recover on the mental_note
function.
Thankfully, it has a lot of RAM and is doing little else than serving as
svn repository and apache web server so I have been functioning without
issue…I’m gonna cut it down to 4 (tonight) as it is in ‘production’ at
the moment. At this point, there isn’t likely to be more than 4 people
using it.
I am also uncertain how the idle-timeout benefits me being set to 60
which I presume means minutes…I am sweeping sessions at 8 hours.
Craig