# CGI and FastCGI problems

**URL:** <https://www.ruby-forum.com/t/cgi-and-fastcgi-problems/66459>\
**Category:** Rails\
**Created:** [December 15, 2005, 5:48pm UTC](https://www.ruby-forum.com/t/cgi-and-fastcgi-problems/66459 "2005-12-15T17:48:39Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jason\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/87869e/32.png) [@Jason\_E](https://www.ruby-forum.com/u/Jason_E)\
**Post date:** [December 15, 2005, 5:48pm UTC](https://www.ruby-forum.com/t/cgi-and-fastcgi-problems/66459/1 "2005-12-15T17:48:39Z")

</div>

I can’t my rails app to work with cgi or fastcgi.

My app works using webrick. I’ve even hard-coded development mode in  
environment.rb in order to get most descriptive messages, but the best I  
get is the following in the apache2 errorlog:  
[Thu Dec 15 10:38:04 2005] [error] [client x.x.x.x] FastCGI: incomplete  
headers (35 bytes) received from server  
“/path/to/railsapp/public/dispatch.fcgi”

my development.log file is empty.  
my fastcgi-crashlog shows starting and terminated gracefully.

running dispatch.cgi or dispatch.fcgi via “ruby ./dispatch.cgi” returns  
“500: Internal Server Error”

How can I fix this or at least get a more descriptive error message?

Thanks,  
Jason

---

<div class="post-metadata">

**Author:** ![Jason\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/87869e/32.png) [@Jason\_E](https://www.ruby-forum.com/u/Jason_E)\
**Post date:** [December 15, 2005, 8:58pm UTC](https://www.ruby-forum.com/t/cgi-and-fastcgi-problems/66459/2 "2005-12-15T20:58:53Z")

</div>

Jason E. wrote:

> my fastcgi-crashlog shows starting and terminated gracefully.
> 
> running dispatch.cgi or dispatch.fcgi via “ruby ./dispatch.cgi”  
> returns “500: Internal Server Error”
> 
> How can I fix this or at least get a more descriptive error message?

I got it working on my own.

Things started working after I deleted all of the session files lie this  
“rm -f /tmp/ruby\_sess.\*”

Jaosn

---

<div class="post-metadata">

**Author:** ![Jason\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/87869e/32.png) [@Jason\_E](https://www.ruby-forum.com/u/Jason_E)\
**Post date:** [December 16, 2005, 2:22pm UTC](https://www.ruby-forum.com/t/cgi-and-fastcgi-problems/66459/3 "2005-12-16T14:22:11Z")

</div>

We’ve also had this problem and used this solution. However no one here  
has (so far) been able to say what the problem actually is and how to  
cure it long term.

Anyone?

---

<div class="post-metadata">

**Author:** ![Jason\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/87869e/32.png) [@Jason\_E](https://www.ruby-forum.com/u/Jason_E)\
**Post date:** [May 21, 2006, 12:19am UTC](https://www.ruby-forum.com/t/cgi-and-fastcgi-problems/66459/4 "2006-05-21T00:19:11Z")

</div>

Check the permissions on your ./tmp/session folder. If your running uder  
suexec they will have to be something like 01777.

Rick wrote:

> We’ve also had this problem and used this solution. However no one here  
> has (so far) been able to say what the problem actually is and how to  
> cure it long term.
> 
> Anyone?

---

<div class="post-metadata">

**Author:** ![Jason\_E](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/87869e/32.png) [@Jason\_E](https://www.ruby-forum.com/u/Jason_E)\
**Post date:** [December 16, 2005, 2:44pm UTC](https://www.ruby-forum.com/t/cgi-and-fastcgi-problems/66459/5 "2005-12-16T14:44:38Z")

</div>

On Friday 16 December 2005 20:22, Rick wrote:

> We’ve also had this problem and used this solution. However no one here  
> has (so far) been able to say what the problem actually is and how to  
> cure it long term.
> 
> Anyone?

Had been bitten too by this problem for 2 different causes:

1. too many sessions in /tmp dir. Found a solution in the “Ruby on  
Rails”  
book, which is to have cron issuing the following command from time to  
time:

find /tmp/ -name ‘ruby\_sess\*’ -ctime +12h -delete

1. much more fun with change in the application: the objects kept in the  
session file could not be ‘marshaled’ back as their base class has had  
some  
changes. Solution: be sure that the browser is killed “for good”, do not  
try  
to reuse an existing cookie and make a fresh login in the application  
after  
each change.

Francois
