Debian + Apache2 + mod_fcgid + "Application Error"

Hello all,

I’m having a weird problem, which I find very hard to debug. The
production version of my rails app runs on Debian, Apache2 and
mod_fcgid. On the development machines I run WEBrick on Debian and
OSX. I also have test “production” version running on mod_fastcgi and
apache 1 on OSX.

On the production machine (Debian) I get application errors which
don’t appear on any of the other machines. If I switch to running the
app on WEBrick on the same machine and the same database I don’t see
any errors, in fact all goes well.

If I run the app (with the same database data) on my development
machine on WEBrick or on the Apache with mod_fastcgi, all runs well
also. No errors whatsoever.

I’ve posted the stripped code and errors on:
http://www.larik.nl/DHTML/bugs/Rails/rails_problem_mod_fcgid.html

If someone knows what’s going on here, please let me know.


Sincerely,

Frodo L.

Frodo L. wrote:

app on WEBrick on the same machine and the same database I don’t see
any errors, in fact all goes well.

If I run the app (with the same database data) on my development
machine on WEBrick or on the Apache with mod_fastcgi, all runs well
also. No errors whatsoever.

I’ve posted the stripped code and errors on:
http://www.larik.nl/DHTML/bugs/Rails/rails_problem_mod_fcgid.html

I suspect your problem is that ruby/rails is taking too long to start up
the first time and mod_fcgid is killing the process because it sees it
as a timeout. If you look at your apache2 error log (by default
/var/log/apache2/error.log on Debian) you will see messages from
mod_fcgid about shutting down the process.

Check out the directives here:
http://fastcgi.coremail.cn/doc.htm

These are probably the relevant ones for your problem:

IPCConnectTimeout n (2 seconds)
The connect timeout to a fastcgi application.

IPCCommTimeout n (5 seconds)
The communication timeout to a fastcgi application.

Try bumping those limits up in your apache2 conf. Using the Debian
package management system, the conf for mod_fcgid is located here:
/etc/apache2/mods-available/fcgid.conf

eg:
IPCConnectTimeout 10
IPCCommTimeout 25

You will probably have to experiment with the proper timeout values, as
the startup time of ruby/rails depends on the hardware you are running
it on.

-F

On 12/8/05, Finn S. [email protected] wrote:

These are probably the relevant ones for your problem:

IPCConnectTimeout n (2 seconds)
The connect timeout to a fastcgi application.

IPCCommTimeout n (5 seconds)
The communication timeout to a fastcgi application.

I already had them in place, I also bumped them to very high values, but
it
didn’t solve the problem.


Sincerely,

Frodo L.

Frodo L. wrote:

it didn’t solve the problem.
The fact that this works correctly with mod_fastcgi and webrick, but not
with mod_fcgid indicates that the problem is somewhere in the fcgid
configuration or environment. I think to track this down you are going
to have to make the apache2/fcgid logging as verbose as possible and
look in those logs rather than in the rails logs. (Although the rails
fastcgi.crash.log might be helpful.) You also might see if you can get
any other cgis running under mod_fcgid.

-F

Am Freitag, den 09.12.2005, 10:52 -0500 schrieb Finn S.:

I already had them in place, I also bumped them to very high values, but
it didn’t solve the problem.

The fact that this works correctly with mod_fastcgi and webrick, but not
with mod_fcgid indicates that the problem is somewhere in the fcgid
configuration or environment. I think to track this down you are going
to have to make the apache2/fcgid logging as verbose as possible and
look in those logs rather than in the rails logs. (Although the rails
fastcgi.crash.log might be helpful.) You also might see if you can get
any other cgis running under mod_fcgid.

I think it may be a version problem. Try to get the same versions of
each part of software you are using with your application on both
Servers, starting at Rails, followed by gems and at least by Ruby
itself.

I don’t think this is a fcgi problem. But this can be completely wrong.

Does it work if you call dispatch.cgi instead of dispatch.fcgi?

I can say no more to your error, but perhaps you want to follow my
HowTo:

http://www.inlet-media.de/the-perfect-ruby-on-rails-with-apache2-and-fastcgi-setup-on-debian-sarge

I was struggling with similar problems. Finally it helped me (on Sarge
AMD64 + Apache2) to delete all session files from /tmp and restart
apache. On another box (Sid, Apache 1.3) it helped to disable MultiViews
in Apache cfg and delete all session files as well.

On 12/15/05, Jakub C. [email protected] wrote:

I was struggling with similar problems. Finally it helped me (on Sarge
AMD64 + Apache2) to delete all session files from /tmp and restart
apache. On another box (Sid, Apache 1.3) it helped to disable MultiViews
in Apache cfg and delete all session files as well.

My sessions use the database for storage and I don’t use multiviews by
default.

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


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Sincerely,

Frodo L.

On 12/9/05, Finn S. [email protected] wrote:

The fact that this works correctly with mod_fastcgi and webrick, but not

with mod_fcgid indicates that the problem is somewhere in the fcgid
configuration or environment. I think to track this down you are going
to have to make the apache2/fcgid logging as verbose as possible and
look in those logs rather than in the rails logs. (Although the rails
fastcgi.crash.log might be helpful.) You also might see if you can get
any other cgis running under mod_fcgid.

I’m also sure now the problem is with fcgid, pages which contain more
data
now, have trouble loading, espicially with nested templates.


Sincerely,

Frodo L.

On 12/11/05, Norman T. [email protected] wrote:

I think it may be a version problem. Try to get the same versions of
each part of software you are using with your application on both
Servers, starting at Rails, followed by gems and at least by Ruby
itself.

On both systems the are the same.

I don’t think this is a fcgi problem. But this can be completely wrong.

Does it work if you call dispatch.cgi instead of dispatch.fcgi?

Yep.

I can say no more to your error, but perhaps you want to follow my

HowTo:

http://www.inlet-media.de/the-perfect-ruby-on-rails-with-apache2-and-fastcgi-setup-on-debian-sarge

I tried fastcgi before, I didn’t like it because of the processess which
stay running even after restarting apache.

[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Sincerely,

Frodo L.