passenger: Not a Passenger issue (was: Application crashes with uninitialized Rack constant when run in Passenger)

I’ve tried to google for this, tried everything I can think of to figure out why this is happening, but I am at a loss… so I’m asking here. Any idea why this happens with nginx+passenger, but not rackup? It is quite literally a “Hello world” sinatra app at this point in time.

App 23203 stderr: [ 2015-04-15 11:21:12.9206 23224/0x00000000c69850(Worker 1) utils.rb:85 ]: *** Exception NameError in Rack application object (uninitialized constant Rack::MethodOverride::REQUEST_METHOD) (process 23224, thread 0x00000000c69850(Worker 1)):
App 23203 stderr:       from /var/lib/gems/2.1.0/gems/rack-1.6.0/lib/rack/methodoverride.rb:14:in `call'
App 23203 stderr:       from /var/lib/gems/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:181:in `call'
App 23203 stderr:       from /var/lib/gems/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:2021:in `call'
App 23203 stderr:       from /var/lib/gems/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in `block in call'
App 23203 stderr:       from /var/lib/gems/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1795:in `synchronize'
App 23203 stderr:       from /var/lib/gems/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in `call'
App 23203 stderr:       from /usr/lib/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:85:in `process_request'
App 23203 stderr:       from /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:149:in `accept_and_process_next_request'
App 23203 stderr:       from /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:110:in `main_loop'
App 23203 stderr:       from /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler.rb:414:in `block (3 levels) in start_threads'
App 23203 stderr:       from /usr/lib/ruby/vendor_ruby/phusion_passenger/utils.rb:111:in `block in create_thread_and_abort_on_exception'
[ 2015-04-15 11:21:12.9209 23156/7fcb1c2cd700 age/Hel/Req/Utils.cpp:89 ]: [Client 1-1] Sending 502 response: application did not send a complete response

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 25 (10 by maintainers)

Links to this issue

502 Bad gateway error/NameError in Rack application for sinatra app on nginx, passenger in a docker container - Stack Overflow

Commits related to this issue

Prefer loading Rack and Bundler from RubyGems instead of 'vendor_ruby' Closes GH-1478. Closes GH-1480. — committed to phusion/passenger by FooBarWidget 9 years ago

Most upvoted comments

We’ve found the cause of the issue. It is not a Passenger bug.

Your system has two Rack versions installed. One is version 1.5.0, installed by APT, and is located in /usr/lib/ruby/vendor_ruby. The other one is version 1.6.0, installed by RubyGems, and is located in /var/lib/gems/2.1.0/gems/rack-1.6.0.

Before Passenger loads your app, Passenger calls require "rack". Because /usr/lib/ruby/vendor_ruby is in Ruby’s $LOAD_PATH, Passenger loads the Rack 1.5.0 library installed by APT.

However Sinatra requires Rack 1.6.0 or later, so at some point it tries to load a file not found in Rack 1.5.0. At that point, RubyGems kicks in and loads rack/request.rb from /var/lib/gems/2.1.0/gems/rack-1.6.0. Now you’ve ended up with two conflicting versions of Rack loaded in the same Ruby process, and things break.

The solution is to use a Gemfile. This way, Bundler will ensure that /var/lib/gems/2.1.0/gems/rack-1.6.0 is in $LOAD_PATH first.

The reason why ‘rackup’ worked for you, is because the ‘rackup’ command that is first in your $PATH is the one installed by RubyGems, and not the one installed by APT. The ‘rackup’ command installed by RubyGems activates the rack 1.6.0 gem, and ensures that /var/lib/gems/2.1.0/gems/rack-1.6.0 is in $LOAD_PATH first. Thus, it happens to bypass the problem.

I am on OS X, so I don’t have rack.rb installed in /usr/lib/ruby/vendor_ruby, and so I couldn’t reproduce your problem.

FooBarWidget on Apr 16, 2015