No commands working in Production

rubyonrails-talk
1

I’m having an issue getting my app to start up in production. After spending a lot of time trying to troubleshoot differences between production and development servers, I set up a clean Ubuntu 14.04 server on EC2. Everything runs fine in the development environment, but as soon as I try to do anything in the production environment, it fails immediately with no errors and no logs (that I can find). See below for what I’m getting on the command line when trying to start the server or create the database.

Starting server in Development:

ubuntu@ip-172-31-27-6:~/myapp$ rails s puma -b ec2-54-173-179-250.compute-1.amazonaws.com

=> Booting Puma

=> Rails 4.2.0 application starting in development on http://ec2-54-173-179-250.compute-1.amazonaws.com:3000

=> Run rails server -h for more startup options

=> Ctrl-C to shutdown server

Puma 2.11.1 starting…

  • Min threads: 0, max threads: 16
  • Environment: development
  • Listening on tcp://ec2-54-173-179-250.compute-1.amazonaws.com:3000

**Starting server in **Production:

ubuntu@ip-172-31-27-6:~/myapp$ rails s puma -b ec2-54-173-179-250.compute-1.amazonaws.com -e production

=> Booting Puma

=> Rails 4.2.0 application starting in production on http://ec2-54-173-179-250.compute-1.amazonaws.com:3000

=> Run rails server -h for more startup options

=> Ctrl-C to shutdown server

Abort testing: Your Rails environment is running in production mode!

Exiting

ubuntu@ip-172-31-27-6:~/myapp$

Creating DB in Development

ubuntu@ip-172-31-27-6:~/myapp$ RAILS_ENV=development rake db:create db:schema:load

– enable_extension(“plpgsql”)

→ 0.0241s

– create_table(“clients”, {:force=>:cascade})

→ 0.0195s

– add_index(“clients”, [“user_id”], {:name=>“index_clients_on_user_id”, :using=>:btree})

→ 0.0071s

– create_table(“pieces”, {:force=>:cascade})

→ 0.0134s

– add_index(“pieces”, [“user_id”], {:name=>“index_pieces_on_user_id”, :using=>:btree})

→ 0.0075s

– create_table(“rentals”, {:force=>:cascade})

→ 0.0065s

– add_index(“rentals”, [“client_id”], {:name=>“index_rentals_on_client_id”, :using=>:btree})

→ 0.0063s

– add_index(“rentals”, [“piece_id”], {:name=>“index_rentals_on_piece_id”, :using=>:btree})

→ 0.0065s

– create_table(“users”, {:force=>:cascade})

→ 0.0111s

– add_index(“users”, [“email”], {:name=>“index_users_on_email”, :unique=>true, :using=>:btree})

→ 0.0057s

– add_foreign_key(“clients”, “users”)

→ 0.0032s

– add_foreign_key(“pieces”, “users”)

→ 0.0020s

– initialize_schema_migrations_table()

→ 0.0140s

Started

0/0: [==================================================================================================] 100% Time: 00:00:00, Time: 00:00:00

Creating DB in Production:

ubuntu@ip-172-31-27-6:~/myapp$ RAILS_ENV=production rake db:create db:schema:load

Abort testing: Your Rails environment is running in production mode!

ubuntu@ip-172-31-27-6:~/myapp$

In this case, the production database is created, but the tables aren’t.

Basically, running any command seems to stop after getting the message “Abort testing: Your Rails environment is running in production mode!” I’ve tried pointing to the already-created dev database in database.yml and running the server, but I get the same problem. I’ve tried using WEBrick, puma and unicorn. All end up with the same issue. I even copied environments/development.rb to environments/production.rb, with no luck.

I’m new to RoR and this kind of development environment. I don’t even know where to begin troubleshooting this, so any help would be appreciated.

Thanks

Mark

2

Looks like someone was very paranoid about running in production mode - I’d search the code base for instances of that warning message. It seems that by default this is included in test_help.rb (generated as part of a rails app), so it’s possible that’s been required somehow.

Fred

3

You, sir, are a giant among men.

I assumed the message about running in production was a standard message whenever running in that environment. Commenting out “require ‘rails/test_help’” in environment.rb did the trick.

Thanks!

Mark