views:

1288

answers:

6

I've setup Ruby 1.9.1 (p234) on a Ubuntu server. I'm trying to deploy a Rails app which vendors Rails 2.3-stable on Apache 2.2/Passenger 2.2.5.

GET requests work fine, POST requests break immediately with the following log entry:

Processing UsersController#new (for 80.203.77.44 at 2009-10-24 20:54:55) [GET]
  Parameters: {"controller"=>"users", "action"=>"new"}
Rendering template within layouts/application
Rendering users/new
Completed in 23ms (View: 20, DB: 0) | 200 OK [http://myapp/user/new]
/!\ FAILSAFE /!\  2009-10-24 20:55:01 +0200
  Status: 500 Internal Server Error
  closed stream
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/rewindable_input.rb:86:in make_rewindable'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/rewindable_input.rb:26:inread'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/request.rb:136:in POST'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/methodoverride.rb:15:incall'
    /var/www/myapp/app/releases/20091021213913/vendor/rails/actionpack/lib/action_controller/params_parser.rb:15:in call'
    /var/www/myapp/app/releases/20091021213913/vendor/rails/actionpack/lib/action_controller/session/cookie_store.rb:93:incall'
    /var/www/myapp/app/releases/20091021213913/vendor/rails/actionpack/lib/action_controller/failsafe.rb:26:in call'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:inblock in call'
    :8:in synchronize'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/vendor/rack-1.0.0-git/lib/rack/lock.rb:11:incall'
    /var/www/myapp/app/releases/20091021213913/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:106:in call'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/rack/request_handler.rb:95:inprocess_request'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/abstract_request_handler.rb:207:in main_loop'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:378:instart_request_handler'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:336:in block in handle_spawn_application'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb:183:insafe_fork'
    /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application'

...and then some.

I've read up, and found this: http://blog.labnotes.org/2009/09/01/ruby-1-9-1-p234passenger-2-2-5-tempfile-rb-fix/ which points to a patch that removes a single line from Ruby 1.9.1-p234's tempfile.rb. Unfortunately for me, inspecting that file I find that the offensive line has already been removed. So that leaves me a bit clueless, as my problem persists. Any ideas?

A: 

Hey Damien. I had the same problem and whilst i havent got an exact answer/link for you from memory i had to patch rack and not tempfile. I hope this helps

ADAM
Exactly how did you patch Rack? I noticed that Passenger vendors a pre-1.0.0 version of Rack. I tried to replace the vendored version with Rack 1.0.1, but keep getting the same error.
Christian
+2  A: 

I had to do the following to make it work

gems/passenger-2.2.5/lib/phusion_passenger/utils.rb add require 'stringio' to that file on line 34

open lib/ruby/1.9.1/tempfile.rb comment out line 140

And it works like a charm.

Casual Jim
Thanks for chipping in. However, I'm still not getting anywhere. Would you mind posting your tempfile? I cannot understand how my tempfile looks different from other people using the same version of Ruby.
Christian
worked perfect, thanks
Jordan Brough
+5  A: 

There is a workaround in passenger 2.2.8 so this is no longer needed.

Casual Jim's response above worked for me. Thanks very much Jim for your help.

The diffs on my system are, respectively, as follows. I hope this is helpful.

Killian.

*** /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb.orig Tue Nov  3 17:43:30 2009
--- /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb  Tue Nov  3 17:43:46 2009
***************
*** 31,36 ****
--- 31,37 ----
  require 'etc'
  require 'fcntl'
  require 'tempfile'
+ require 'stringio'
  require 'phusion_passenger/exceptions'
  if !defined?(RUBY_ENGINE) || RUBY_ENGINE == "ruby"
    require 'phusion_passenger/native_support'


*** /usr/local/lib/ruby/1.9.1/tempfile.rb.orig  Tue Nov  3 17:44:34 2009
--- /usr/local/lib/ruby/1.9.1/tempfile.rb   Tue Nov  3 17:45:55 2009
***************
*** 137,143 ****
      # keep this order for thread safeness
      begin
        if File.exist?(@tmpname)
!         closed? or close
          File.unlink(@tmpname)
        end
        @@cleanlist.delete(@tmpname)
--- 137,143 ----
      # keep this order for thread safeness
      begin
        if File.exist?(@tmpname)
!         # closed? or close
          File.unlink(@tmpname)
        end
        @@cleanlist.delete(@tmpname)
Killian
Wow, thanks alot for posting that! I've been confusing that magic "line 140" with another tempfile fix (described here: http://blog.labnotes.org/2009/09/01/ruby-1-9-1-p234passenger-2-2-5-tempfile-rb-fix/) and tried to fix the wrong thing. It works now, thanks alot!
Christian
Does this now work with the latest passenger?
Ryan Bigg
A: 

Casual Jim's fix worked for me, thanks, this problem was driving me nuts.

I also had to patch actionview (per hector gomez's patch at https://rails.lighthouseapp.com/projects/8994/tickets/2188-i18n-fails-with-multibyte-strings-in-ruby-19-similar-to-2038) to get rails and ruby 1.9.1 working.

I'm running Rails 2-3-stable from git, it works without patching.
Christian
A: 

Hi Casual Jim, Great man you are...:) its working for me. Thank you lot

Murugan
A: 

When applying this fix, I cannot restart the Passenger module more than a few time using the tmp/restart.txt method. After that, requests are accepted but never served. I suspect that the patch may be leaking tempfiles

Anders Johannsen