This project is archived and is in readonly mode.

#1854 ✓ resolved
Alexander Semyonov

FastCGI dispatcher don't work

Reported by Alexander Semyonov | February 3rd, 2009 @ 03:51 AM

After update to rails 2.3 FastCGI server won't respond.

in fastcgi.crash.log:

Dispatcher failed to catch: undefined method env' for #<CGI:0xb78e0208> (NoMethodError) /usr/lib/ruby/gems/1.8/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:inserve' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:101:in process_request' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:151:inwith_signal_handler' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:99:in process_request' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:76:inprocess_each_request' /usr/lib/ruby/1.8/fcgi.rb:606:in each_cgi' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:75:inprocess_each_request' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:74:in catch' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:74:inprocess_each_request' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:49:in process!' /home/rotuka/Sites/croconize/vendor/rails/railties/lib/fcgi_handler.rb:23:inprocess!' ./public/dispatch.fcgi:30 unhandled dispatch error

Comments and changes to this ticket

  • Alexander Semyonov

    Alexander Semyonov February 3rd, 2009 @ 10:58 PM

    • Tag changed from 2.3, fastcgi, rack to 2.3, bug, fastcgi, rack
    • Assigned user set to “Joshua Peek”
  • DHH

    DHH February 3rd, 2009 @ 11:04 PM

    • Milestone cleared.
  • Joshua Peek

    Joshua Peek February 3rd, 2009 @ 11:30 PM

    I know you probably can't create a unit test for this, but can you please give me some steps to reproduce it. Like what server is in front, apache or lighttpd?

  • Will Green

    Will Green February 4th, 2009 @ 03:51 AM

    I see similar behavior with IIS7 + FastCGI + Ruby One-Click installer 1.8.6-26

    [03/Feb/2009:22:38:55 :: 1972] Ignoring unsupported signal USR1. [03/Feb/2009:22:38:55 :: 1972] Dispatcher failed to catch: undefined method env' for #<FCGI::CGI:0x424378c> (NoMethodError) C:/ruby/lib/ruby/gems/1.8/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:inserve' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:101:in process_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:151:inwith_signal_handler' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:99:in process_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:76:inprocess_each_request' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:612:in each_cgi' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:609:ineach' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:609:in each_cgi' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:75:inprocess_each_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:74:in catch' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:74:inprocess_each_request' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:49:in process!' C:/ruby/lib/ruby/gems/1.8/gems/rails-2.3.0/lib/fcgi_handler.rb:23:inprocess!' c:/development/myapp/public/dispatch.fcgi:24 unhandled dispatch error

  • Will Green

    Will Green February 4th, 2009 @ 04:06 AM

    FWIW, I had IIS7 + FastCGI + Rails 2.2.2 working. All I did was update the app to Rails 2.3.0.

  • Will Green

    Will Green February 4th, 2009 @ 04:58 AM

    I think you might be expecting a different class of object for the request variable. I think you're expecting an FCGI::CGI::Request or CGI::Request, but the error log shows that you're getting an FCGI::CGI or CGI object instead.

  • Alexander Semyonov

    Alexander Semyonov February 4th, 2009 @ 10:10 AM

    Apache2 + mod_fastcgi + rails2.3. Application doesn't work.

    dispatcher.fcgi shows me "502 Bad Gateway" and put nothing in logs

    When I run dispatcher manually ($ ./public/dispatch.fcgi) there are the same errors (like in first post)

    dispatcher.cgi shows "Application Error" that written in .htaccess and in logs there are:

    /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/cgi_process.rb:22:in __send__': You have a nil object when you didn't expect it! (NoMethodError) The error occurred while evaluating nil.env_table

    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/cgi_process.rb:22:in `dispatch_cgi'
    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/dispatcher.rb:79:in `dispatch_cgi'
    from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.0/lib/action_controller/dispatcher.rb:29:in `dispatch'
    from ./public/dispatch.cgi:10
    
    
  • Will Green

    Will Green February 5th, 2009 @ 03:25 AM

    Looking at the spec for the Rack FastCGI handler, 3 things immediately jump out at me:

    • Line 8 : @host = '0.0.0.0' This is not a valid address on Windows. Should change to 127.0.0.1
    • Line 14 : the use of fork fork is not implemented on Windows. The win32-process gem is needed to get this working (conditional require?)
    • Line 16 : lighttpd There is an unstated dependency on Lighttpd

    I'll try to get these in place and run the spec again. I think that is why all the examples in the spec fail right now:

    C:\ruby\lib\ruby\gems\1.8\gems\rack-0.9.1\test>spec spec_rack_fastcgi.rb FFFFFFFFF

    1) NotImplementedError in 'Rack::Handler::FastCGI startup' fork() function is unimplemented on this machine ./spec_rack_fastcgi.rb:14:in fork' ./spec_rack_fastcgi.rb:14:

    2) Test::Unit::AssertionFailedError in 'Rack::Handler::FastCGI should respond' Exception raised: Class: <Errno::EADDRNOTAVAIL> Message: <"The requested address is not valid in its context. - connect(2)"> ---Backtrace--- C:/Ruby/lib/ruby/1.8/net/http.rb:564:in initialize' C:/Ruby/lib/ruby/1.8/net/http.rb:564:inopen' C:/Ruby/lib/ruby/1.8/net/http.rb:564:in connect' C:/Ruby/lib/ruby/1.8/timeout.rb:48:intimeout' C:/Ruby/lib/ruby/1.8/timeout.rb:76:in timeout' C:/Ruby/lib/ruby/1.8/net/http.rb:564:inconnect' C:/Ruby/lib/ruby/1.8/net/http.rb:557:in do_start' C:/Ruby/lib/ruby/1.8/net/http.rb:546:instart' C:/Ruby/lib/ruby/1.8/net/http.rb:440:in start' ./testrequest.rb:17:inGET'

    ./spec_rack_fastcgi.rb:23

    ./spec_rack_fastcgi.rb:22:

    3) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should be a lighttpd' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:28:

    4) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should have rack headers' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:38:

    5) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should have CGI headers on GET' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:46:

    6) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should have CGI headers on POST'

    The requested address is not valid in its context. - connect(2) ./testrequest.rb:31:in POST' ./spec_rack_fastcgi.rb:63:

    7) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should support HTTP auth' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:74:

    8) Errno::EADDRNOTAVAIL in 'Rack::Handler::FastCGI should set status' The requested address is not valid in its context. - connect(2) ./testrequest.rb:17:in GET' ./spec_rack_fastcgi.rb:79:

    9) TypeError in 'Rack::Handler::FastCGI shutdown' wrong argument type nil (expected Fixnum) ./spec_rack_fastcgi.rb:86:in kill' ./spec_rack_fastcgi.rb:86:

    Finished in 1.23 seconds

    9 examples, 9 failures

  • Peter Wagenet

    Peter Wagenet February 5th, 2009 @ 07:13 PM

    I'm getting the same error. Running on hostingrails.com with Apache.

    
    05/Feb/2009:13:10:16 :: 15387] Dispatcher failed to catch: request: #<FCGI::CGI:0xb6ecab60 @args=nil, @params={}, @cookies={"_trunk_session"=>["BAh7ByIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsGOhFub3RpY2VfZXJyb3IiaFNvcnJ5ISBUaGlzIGFjY291bnQgaW4gbm90IHJlZ2lzdGVyZWQgd2l0aCB1cy4gUGxlYXNlIGVuc3VyZSB0aGF0IHlvdSBoYXZlIGVudGVyZWQgdGhlIGNvcnJlY3QgdXJsLgY6CkB1c2VkewY7BkY6DGNzcmZfaWQiJWY4MzI5NDU2NDNiMmMwYjAyMzdiNTk0YmUzNzI4NGMz--014da862ca2ba93f9d3be2e3121afad5d8b2bc91"]}, @output_hidden=nil, @request=#<FCGI:0xb6ecb510>, @output_cookies=nil, @multipart=false> (RuntimeError)
      /home/mygalax/webapps/dev/vendor/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:in `serve'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:101:in `process_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:151:in `with_signal_handler'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:99:in `process_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:76:in `process_each_request'
      /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:in `each_cgi'
      /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each'
      /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each_cgi'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:75:in `process_each_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `catch'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `process_each_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:49:in `process!'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:23:in `process!'
      dispatch.fcgi:25
    unhandled dispatch error
    
  • Peter Wagenet

    Peter Wagenet February 5th, 2009 @ 07:15 PM

    Whoops, didn't realize that the error was actually different that time. I've also gotten:

    
    [05/Feb/2009:13:08:49 :: 14855] Dispatcher failed to catch: undefined method `env' for #<FCGI::CGI:0xb6f5ff1c> (NoMethodError)
      /home/mygalax/webapps/dev/vendor/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:in `serve'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:101:in `process_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:151:in `with_signal_handler'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:99:in `process_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:76:in `process_each_request'
      /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:in `each_cgi'
      /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each'
      /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in `each_cgi'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:75:in `process_each_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `catch'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:74:in `process_each_request'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:49:in `process!'
      /home/mygalax/webapps/dev/vendor/rails/railties/lib/fcgi_handler.rb:23:in `process!'
      dispatch.fcgi:25
    unhandled dispatch error
    
  • Peter Wagenet

    Peter Wagenet February 5th, 2009 @ 07:17 PM

    Crap. You can ignore the "Dispatcher failed to catch: request" error. That was my fault. The "env" one still stands though. Sorry about that.

  • Peter Wagenet

    Peter Wagenet February 5th, 2009 @ 08:31 PM

    • Tag changed from 2.3, bug, fastcgi, rack to 2.3, bug, fastcgi, patch, rack

    I have a fix for this that at least allows the site to run. I'm not sure if it's really correct but it does at least work, so it's a start. Patch is attached.

  • Repository

    Repository February 5th, 2009 @ 10:22 PM

    • State changed from “new” to “resolved”

    (from [dcc2407d9976740cebe6736ec6adeae269b81203]) Fixed FCGI handling [#1854 state:resolved]

    Signed-off-by: Joshua Peek josh@joshpeek.com http://github.com/rails/rails/co...

  • Joshua Peek

    Joshua Peek February 5th, 2009 @ 10:23 PM

    Awesome work Peter!

    Alexander and Will does this fix your issue?

  • Joshua Peek

    Joshua Peek February 6th, 2009 @ 01:40 AM

    • State changed from “resolved” to “open”

    Sorry, I had to revert it. It broke some tests.

  • Repository

    Repository February 6th, 2009 @ 01:40 AM

    • State changed from “open” to “resolved”

    (from [f75b98d67ed9ef85d20858a1d24ee6767d64ece6]) Revert "Fixed FCGI handling [#1854 state:resolved]"

    This reverts commit dcc2407d9976740cebe6736ec6adeae269b81203. http://github.com/rails/rails/co...

  • Peter Wagenet

    Peter Wagenet February 6th, 2009 @ 01:45 AM

    No problem. I wasn't convinced it was exactly the right fix, just the start of one. I'll look into the tests and see if I can figure anything out. In the meantime if anyone else wants to build on what I've done they're more than welcome to.

  • Will Green

    Will Green February 6th, 2009 @ 02:31 AM

    Patch was no good on windows/IIS7:

    Dispatcher failed to catch: Bad file descriptor (Errno::EBADF) c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:102:in write' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:102:inid' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:102:in process_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:153:inwith_signal_handler' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:100:in process_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:77:inprocess_each_request' C:/ruby/lib/ruby/site_ruby/1.8/fcgi.rb:606:in each_cgi' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:76:inprocess_each_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:75:in catch' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:75:inprocess_each_request' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:50:in process!' c:/development/myapp/vendor/rails/railties/lib/fcgi_handler.rb:24:inprocess!' c:/development/myapp/public/dispatch.fcgi:24 unhandled dispatch error

  • Peter Wagenet

    Peter Wagenet February 6th, 2009 @ 04:01 AM

    • Tag changed from 2.3, bug, fastcgi, patch, rack to 2.3, bug, fastcgi, patch, rack, tested

    @Will, I'm not sure what's going on there. I don't have IIS7 to test on myself.

    Anyway, I've attached an updated patch with working tests. This patch solves the problem in some cases at least.

  • Joshua Peek

    Joshua Peek February 6th, 2009 @ 04:41 AM

    • State changed from “resolved” to “open”

    Is this something that should be patched upstream on Rack's FCGI server?

    I'm going to look into this more this weekend. Ideally we could push some of the signal handling up to Rack so you'd just use it instead.

  • Peter Wagenet

    Peter Wagenet February 6th, 2009 @ 04:55 AM

    Yeah, one problem I see is that the tests just mock out the requests. So we're just assuming that we get a certain kind of object FCGI::Request, but we're actually getting FCGI::CGI. Nothing is actually testing to make sure we're getting the right object. Secondly, the C based FCGI doesn't appear to include the FCGI::Request class. I had to force it to load the pure Ruby version of FCGI for that bit to work. I haven't yet hunted down where the FCGI::CGI request is coming from so I'm not sure if it's a problem with what Rack is providing or what Rails is expecting.

  • Jan De Poorter

    Jan De Poorter February 6th, 2009 @ 08:20 AM

    As far as I could have a look at it problem was that provider.each_cgi sends a different object then Rack is expecting. The solution for me was to change it to provider.each, but I know this breaks some other things down the code, so someone with some clue about the whole thing should have a look.

  • Peter Wagenet

    Peter Wagenet February 6th, 2009 @ 03:45 PM

    @Jan, that fits with what I'm seeing. If you open up the fcgi gem (0.8.7) you see that in lib/fcgi.rb FCGI::each_cgi explicitly returns a CGI object. Then the fcgi_handler.rb goes on to call methods that aren't defined on the CGI object. The only possible explanations I can think of are that someone just goofed and thought it was a Request object (which my patch changes it to), or the CGI class is defined differently somewhere else (possibly Ruby 1.9?).

    So before we can do a proper fix there are a few questions we need answered: 1) What kind of object should we be expecting. Should it be a CGI object as the variable naming implies? Or should it be a Request object. 2a) If a CGI object, should we be converting it to a Request or instead calling methods that actually exist on the CGI object (i.e. stdinput, stdoutput, env_table)? 2b) If a Request object, how should it be generated? Is FCGI::each the appropriate way?

    Once we can answer these questions I think we can then get a full fix out the door.

  • Repository

    Repository February 7th, 2009 @ 06:26 AM

    • State changed from “open” to “resolved”

    (from [2316e7dfb16518d4d0d92165bcd53b262080fc37]) Fix FCGI handler with lighttpd [#1854 state:resolved] http://github.com/rails/rails/co...

  • Joshua Peek

    Joshua Peek February 7th, 2009 @ 06:31 AM

    I've verified it against lighttpd on OS X. Can you guys please test on windows.

  • Will Green

    Will Green February 7th, 2009 @ 01:55 PM

    Confirmed working on IIS7 + FastCGI.

  • Peter Wagenet

    Peter Wagenet February 7th, 2009 @ 04:15 PM

    Confirmed on Apache/2.2.8 (Unix)

  • Joshua Peek

    Joshua Peek February 7th, 2009 @ 05:01 PM

    Sweet!

    I'm going try to get those fancy signal handlers pushed up to Rack core now.

  • Peter Wagenet

    Peter Wagenet February 7th, 2009 @ 05:10 PM

    Sounds good. Let me know if you need any help with testing.

  • Shawn

    Shawn March 5th, 2009 @ 11:25 AM

    Peter,.. You said you were on HostingRails.com and that you got this working?

    I am butting up against this problem too.

    starting [05/Mar/2009:04:50:43 :: 4414] Dispatcher failed to catch: undefined method env' for #<FCGI::CGI:0xb75be458> (NoMethodError) /usr/local/lib/ruby/gems/1.8/gems/rack-0.9.1/lib/rack/handler/fastcgi.rb:32:inserve' /home/gfmerde/rhlebm3/vendor/rails/railties/lib/fcgi_handler.rb:101:in process_request' blah blah blah

    Am I able to apply your patch locally to something/somewhere in my app, or do I have to convince someone at hostingrails.com to do this? Or do I have to renounce 2.3 ? :-( sniff.

    My out-of-bandwidth email is shawn@shawnkoppenhoefer.com by the way. Thanks!

  • Peter Wagenet

    Peter Wagenet March 5th, 2009 @ 02:46 PM

    @Shawn,

    You'll want to freeze Rails into vendor to avoid being stuck with HostingRails' version. If you freeze edge, you should be set. If you want to freeze 2.3 RC1 then try applying Joshua's patch here: http://github.com/rails/rails/co...

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Tickets have moved to Github

The new ticket tracker is available at https://github.com/rails/rails/issues

Shared Ticket Bins

Attachments

Referenced by

Pages