Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ActiveRecord::AdapterNotSpecified bug in latest update (6.0.5) #2281

Closed
mikero opened this issue Jun 2, 2020 · 19 comments
Closed

ActiveRecord::AdapterNotSpecified bug in latest update (6.0.5) #2281

mikero opened this issue Jun 2, 2020 · 19 comments

Comments

@mikero
Copy link

mikero commented Jun 2, 2020

I performed an "apt update" on one of our Ubuntu 18.04 staging servers, and the update included Passenger version 6.0.5. Immediately after installing this update, our application started throwing the following error:

Error: The application encountered the following error: 'staging' database is not configured. Available: [] (ActiveRecord::AdapterNotSpecified)

I was able to track down the cause of the error to the following Passenger commit:

3790eec#diff-696bdc7bb15daaa28a5f17914682f671

Manually reverting this commit to loader_shared_helpers.rb and restarting Nginx fixed the problem for us.

We are running a Ruby Cuba app, using ActiveRecord 5.2, with open source Passenger/Nginx, on Ubuntu 18.04.4 LTS. Ruby 2.5.1p57. Not sure if this affects Rails apps.

Happy to provide more info if needed.

Thanks

@pablolp99
Copy link

pablolp99 commented Jun 2, 2020

Same here. I am building a docker image with the phusion/passenger-ruby26 and setting my environment variables for production stage. Had to update some scripts and rebuilt my image and i'm getting

Error: The application encountered the following error: 'production' database is not configured. Available: [] (ActiveRecord::AdapterNotSpecified)

I looked a lot to the updated code in search for some error in it. But is pretty much like the old code I had. Found this issue and it's verry similar to the problem I have.

Full backtrace:

Rails backports are deprecated.
/usr/local/rvm/gems/ruby-2.6.6/gems/activesupport-4.2.11.1/lib/active_support/core_ext/object/duplicable.rb:111: warning: BigDecimal.new is deprecated; use BigDecimal() method instead.
Error: The application encountered the following error: 'production' database is not configured. Available: [] (ActiveRecord::AdapterNotSpecified)
    /usr/local/rvm/gems/ruby-2.6.6/gems/activerecord-4.2.11.1/lib/active_record/connection_adapters/connection_specification.rb:248:in `resolve_symbol_connection'
    /usr/local/rvm/gems/ruby-2.6.6/gems/activerecord-4.2.11.1/lib/active_record/connection_adapters/connection_specification.rb:211:in `resolve_connection'
    /usr/local/rvm/gems/ruby-2.6.6/gems/activerecord-4.2.11.1/lib/active_record/connection_adapters/connection_specification.rb:139:in `resolve'
    /usr/local/rvm/gems/ruby-2.6.6/gems/activerecord-4.2.11.1/lib/active_record/connection_adapters/connection_specification.rb:169:in `spec'
    /usr/local/rvm/gems/ruby-2.6.6/gems/activerecord-4.2.11.1/lib/active_record/connection_handling.rb:50:in `establish_connection'
    /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:320:in `before_handling_requests'
    /usr/share/passenger/helper-scripts/rack-preloader.rb:159:in `block in negotiate_spawn_command'
    /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:378:in `run_block_and_record_step_progress'
    /usr/share/passenger/helper-scripts/rack-preloader.rb:158:in `negotiate_spawn_command'
    /usr/share/passenger/helper-scripts/rack-preloader.rb:211:in `<module:App>'
    /usr/share/passenger/helper-scripts/rack-preloader.rb:30:in `<module:PhusionPassenger>'
    /usr/share/passenger/helper-scripts/rack-preloader.rb:29:in `<main>'
[ E 2020-06-02 18:52:54.4440 34/T1h age/Cor/App/Implementation.cpp:221 ]: Could not spawn process for application /my/own/application: The application encountered the following error: 'production' database is not configured. Available: [] (ActiveRecord::AdapterNotSpecified)```

Checked the database.yml and it's correct

Hope to have a quick solution

@3mammoth
Copy link

3mammoth commented Jun 3, 2020

Same here.

This seems to be the culprit:
#2253
3790eec

@CamJN
Copy link
Contributor

CamJN commented Jun 3, 2020

I didn't see this come up in my testing, can someone provide a Dockerfile that repproduces the issue please?

@3mammoth
Copy link

3mammoth commented Jun 3, 2020

I didn't see this come up in my testing, can someone provide a Dockerfile that repproduces the issue please?

I can't speak for other people. My company uses MongoDB along with Rails. If you follow the official way to support MongoDB in Rails, ActiveRecord::Base.establish_connection will always throw an exception. Previously, in 6.0.4, the ActiveRecord::Base.connected? check guarded against that.

@dlundgren
Copy link

This is happening in a Sinatra web app as well.

@dop-amine
Copy link

Also happening to our sinatra app. Had to roll back to 6.0.4

@CamJN
Copy link
Contributor

CamJN commented Jun 15, 2020

So it looks like the issue might be that ActiveRecord::Base is present but not configured. The instructions at https://docs.mongodb.com/mongoid/current/tutorials/getting-started-rails/#activerecord-configuration indicate to remove ActiveRecord completely. Can someone who has this issue check if ActiveRecord is present in your Gemfile.lock and if removing it helps?

@3mammoth
Copy link

3mammoth commented Jun 15, 2020 via email

@dlundgren
Copy link

We are using ActiveRecord in our Sinatra app, so removing it would break it.

@CamJN
Copy link
Contributor

CamJN commented Jul 6, 2020

@dlundgren and @mikero you are using ActiveRecord but ActiveRecord throws ActiveRecord::AdapterNotSpecified can you tell me how ActiveRecord gets configured in your apps and when that happens during the startup process?

@shamangeorge
Copy link

this is happening on our apps as well, with active record disabled

@CamJN
Copy link
Contributor

CamJN commented Jul 7, 2020

@3mammoth my mongo test app works fine in passenger 6.0.5: https://github.com/CamJN/mongotest

@hallucinations
Copy link

I have a legacy application on Sinatra that uses a custom DB connection with ActiveRecord::Base.establish_connection that was working till it was updated to 6.0.4. No longer works with 6.0.5.

@mikero
Copy link
Author

mikero commented Jul 14, 2020

@dlundgren and @mikero you are using ActiveRecord but ActiveRecord throws ActiveRecord::AdapterNotSpecified can you tell me how ActiveRecord gets configured in your apps and when that happens during the startup process?

Here's how we're configuring ActiveRecord in our Cuba apps. I've also found the same issue with some Sinatra apps we're running as well, and we configure ActiveRecord in the same manner.

db_config = YAML.load_file("db/config.yml")
ActiveRecord::Base.establish_connection(db_config[ENV['RACK_ENV']])

@CamJN
Copy link
Contributor

CamJN commented Jul 27, 2020

Ok, I think I'll just rescue in the case where the config is not in config/database.yml. ref: https://apidock.com/rails/ActiveRecord/AdapterNotSpecified

@ihower
Copy link

ihower commented Jul 30, 2020

I think the issue is 3790eec#diff-696bdc7bb15daaa28a5f17914682f671 calls ActiveRecord::Base.establish_connection without any arguments and for non-rails project like Sinatra will cause error because the default ActiveRecord::Base.configurations is empty. 😩

I use the following config code to my Sinatra project as workaround:

 ActiveRecord::Base.configurations = { "production" =>  {"adapter"=>"sqlite3", "database"=>"db/production.sqlite3" } }

jbutte added a commit to instructure/passenger-nginx-alpine that referenced this issue Jul 30, 2020
phusion/passenger#2281 this bug
is affecting canvas builds, so we are pinning passenger to
6.0.4 until it has been resolved.
@CamJN
Copy link
Contributor

CamJN commented Aug 3, 2020

Yes, @ihower is correct. And the next version of Passenger should handle this case. Thanks to everyone who helped debug this issue.

@mikecmpbll
Copy link

i'm not really sure that calling ActiveRecord::Base.establish_connection is the right thing for passenger to do, personally. we have connection logic that is set up on app initialization which is being blasted away by this.

what's the advantage of passenger doing this?

@CamJN
Copy link
Contributor

CamJN commented Sep 23, 2020

Passenger has to close all database connections after forking so that the pool works properly, so we reestablish the connection so that the first request after a process is started up doesn't take an extra long time. See here: https://www.phusionpassenger.com/docs/advanced_guides/in_depth/ruby/spawn_methods.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests