Forum: Ruby on Rails Apache Deployment Woes

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B4c1cb6a6c3de25a7ca991d5c7822b27?d=identicon&s=25 mgbaron (Guest)
on 2006-04-05 17:29
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:

1.  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.

2.  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.

3.  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):

<IfModule mod_fastcgi.c>
  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
</IfModule>

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
4daf0b71d5d9a3882e583c0e72eaf5dc?d=identicon&s=25 Alan Francis (Guest)
on 2006-04-05 17:51
Hi Matt,

I found this post:

http://www.fastcgi.com/archives/fastcgi-developers...

Which looks like your problem. A response (which I admit to not
understanding :-) is here:

http://www.fastcgi.com/archives/fastcgi-developers...

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.
4daf0b71d5d9a3882e583c0e72eaf5dc?d=identicon&s=25 Alan Francis (Guest)
on 2006-04-05 17:53
Alan Francis wrote:
> Hi Matt,
>
> I found this post:
>
> http://www.fastcgi.com/archives/fastcgi-developers...
>
> Which looks like your problem. A response (which I admit to not
> understanding :-) is here:
>
> http://www.fastcgi.com/archives/fastcgi-developers...
>
> 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
B4c1cb6a6c3de25a7ca991d5c7822b27?d=identicon&s=25 mgbaron (Guest)
on 2006-04-05 18:07
Alan Francis wrote:
> Hi Matt,
>
> I found this post:
>
> http://www.fastcgi.com/archives/fastcgi-developers...
>
> Which looks like your problem. A response (which I admit to not
> understanding :-) is here:
>
> http://www.fastcgi.com/archives/fastcgi-developers...
>
> 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.
B4c1cb6a6c3de25a7ca991d5c7822b27?d=identicon&s=25 mgbaron (Guest)
on 2006-04-05 18:09
> > 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.
B4c1cb6a6c3de25a7ca991d5c7822b27?d=identicon&s=25 mgbaron (Guest)
on 2006-04-05 18:18
> 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...
B4c1cb6a6c3de25a7ca991d5c7822b27?d=identicon&s=25 mgbaron (Guest)
on 2006-04-05 18:39
Alan Francis wrote:
> Hi Matt,
>
> I found this post:
>
> http://www.fastcgi.com/archives/fastcgi-developers...
>
> Which looks like your problem. A response (which I admit to not
> understanding :-) is here:
>
> http://www.fastcgi.com/archives/fastcgi-developers...
>
> 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?
9618e8fca8d72bf01814276c53c2568c?d=identicon&s=25 Robert MannI (Guest)
on 2006-04-05 18:49
(Received via mailing list)
You are probably restricted to Apache aren't you?

Otherwise you could try using lighttpd, works very well for me.
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-04-05 18:58
(Received via mailing list)
On Wed, 2006-04-05 at 18:39 +0200, mgbaron wrote:
> > http://www.fastcgi.com/archives/fastcgi-developers...
> 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
</Directory>

which is the real directory and life got easier

but I do have this...

<IfModule mod_fastcgi.c>
  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
</IfModule>

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
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-04-05 19:48
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 White wrote:
> On Wed, 2006-04-05 at 18:39 +0200, mgbaron wrote:
>> > http://www.fastcgi.com/archives/fastcgi-developers...
>> 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
> </Directory>
>
> which is the real directory and life got easier
>
> but I do have this...
>
> <IfModule mod_fastcgi.c>
>   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
> </IfModule>
>
> 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
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-04-05 20:42
(Received via mailing list)
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
B4c1cb6a6c3de25a7ca991d5c7822b27?d=identicon&s=25 mgbaron (Guest)
on 2006-04-06 17:29
> ----
> 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!
9ffef62c0a3c095367140a3c08b15971?d=identicon&s=25 Ryan Allen (Guest)
on 2006-04-14 17:52
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.
E28c35323f624b8b9ed8712e25105454?d=identicon&s=25 Ray Baxter (Guest)
on 2006-04-14 20:09
(Received via mailing list)
Ryan Allen 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 topic is locked and can not be replied to.