I only get that error when I run my app in production(Heroku). Locally run ok, I already tested some transactions and it works. I use a Braintree sandbox account
To be specific I get the following error:
2015-05-18T19:07:53.077006+00:00 app[web.1]: Started GET "/transactions/new" for 160.9.0.125 at 2015-05-18 19:07:53 +0000
2015-05-18T19:07:53.093436+00:00 app[web.1]: User Load (1.9ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 1]]
2015-05-18T19:07:53.095900+00:00 app[web.1]: Braintree::ConfigurationError (Braintree::Configuration.merchant_id needs to be set):
2015-05-18T19:07:53.095898+00:00 app[web.1]:
2015-05-18T19:07:53.095902+00:00 app[web.1]: app/controllers/transactions_controller.rb:54:in `generate_new_client_token'
2015-05-18T19:07:53.095903+00:00 app[web.1]: app/controllers/transactions_controller.rb:9:in `new'
2015-05-18T19:07:53.095905+00:00 app[web.1]:
2015-05-18T19:07:53.095906+00:00 app[web.1]:
2015-05-18T19:07:53.089739+00:00 app[web.1]: Processing by TransactionsController#new as HTML
2015-05-18T19:07:53.094330+00:00 app[web.1]: Completed 500 Internal Server Error in 4ms
So my question is If I can use a braintree sandbox account in production or I need to switch to a production account in braintree? Is sandbox causing the error?
config/initializers/braintree.rb
Braintree::Configuration.environment = :sandbox
Braintree::Configuration.logger = Logger.new('log/braintree.log')
Braintree::Configuration.merchant_id = ENV['BRAINTREE_MERCHANT_ID']
Braintree::Configuration.public_key = ENV['BRAINTREE_PUBLIC_KEY']
Braintree::Configuration.private_key = ENV['BRAINTREE_PRIVATE_KEY']
config/application.yml
# Braintree configuration keys
BRAINTREE_MERCHANT_ID: 'XXXXXXXXXXXX'
BRAINTREE_PUBLIC_KEY: 'XXXXXXXXXXXXXX'
BRAINTREE_PRIVATE_KEY: 'XXXXXXXXXXXXXXXXXXX'
The error was with Figaro gem that I am using which do that automatically using ENV and application.yml. I run "rake figaro:heroku[intense-harbor-8486]" in my console and everything running ok. I didn't know that i needed to do that since all gems install in heroku server when I push my app –
Related
I deployed a Rails application in Digital Ocean Ubuntu Server using Capistrano. For some reason the puma server suddenly stops. I'm not sure what's the reason.
That's why I created a script /home/deploy/startup-script.sh
the script contains the commands to startup the Rails application in daemon
#!/bin/bash
echo "Running Puma Server"
touch hello.txt
cd /srv/www/apps/app/current
bundle exec puma -C /srv/www/apps/app/shared/puma.rb --daemon
then I run this script every minute using Cron.
My crontab -e contains
* * * * * ./startup-script.sh
After 1 minute I noticed that it created a hello.txt file but my puma server is not running.
But when I run it manually using ./startup-script.sh it will run the server.
puma_error.log
Puma starting in single mode...
* Version 4.3.1 (ruby 2.6.0-p0), codename: Mysterious Traveller
* Min threads: 0, max threads: 8
* Environment: production
* Daemonizing...
=== puma startup: 2020-09-21 05:16:28 +0000 ===
=== puma startup: 2020-09-21 05:17:39 +0000 ===
* Listening on tcp://0.0.0.0:9292
=== puma startup: 2020-09-21 06:11:35 +0000 ===
- Gracefully stopping, waiting for requests to finish
=== puma shutdown: 2020-09-21 06:11:35 +0000 ===
production.log
Item Load (0.3ms) SELECT "items".* FROM "items" WHERE "items"."id" = $1 LIMIT $2 [["id", 208], ["LIMIT", 1]]
CACHE Unit Load (0.0ms) SELECT "units".* FROM "units" WHERE "units"."id" = $1 LIMIT $2 [["id", 4], ["LIMIT", 1]]
Item Load (0.3ms) SELECT "items".* FROM "items" WHERE "items"."id" = $1 LIMIT $2 [["id", 215], ["LIMIT", 1]]
CACHE Unit Load (0.0ms) SELECT "units".* FROM "units" WHERE "units"."id" = $1 LIMIT $2 [["id", 4], ["LIMIT", 1]]
Item Load (0.2ms) SELECT "items".* FROM "items" WHERE "items"."id" = $1 LIMIT $2 [["id", 198], ["LIMIT", 1]]
CACHE Unit Load (0.0ms) SELECT "units".* FROM "units" WHERE "units"."id" = $1 LIMIT $2 [["id", 10], ["LIMIT", 1]]
Rendering text template
Rendered text template (0.0ms)
Sent data Delivery Receipt 12-2020-001.pdf (0.5ms)
Completed 200 OK in 4326ms (Views: 0.3ms | ActiveRecord: 37.4ms)
puma_access.log
=== puma startup: 2020-12-01 01:07:13 +0000 ===
When starting the startup-script.sh script I'm getting this
Running Puma Server
Puma starting in single mode...
* Version 4.3.1 (ruby 2.6.0-p0), codename: Mysterious Traveller
* Min threads: 0, max threads: 8
* Environment: production
* Daemonizing...
My droplet is still running but the puma running on port 9292 disappears when crashes, so I suspect this is puma error.
Depending on your version of Puma, the --daemon option might be deprecated. Use & instead:
bundle exec puma -C /srv/www/apps/app/shared/puma.rb &
However, your issue isn't with Cron or with Puma. Puma doesn't exit on its own unless something else happens. I recommend that you have a look at the error logs and figure out the real issue.
Edit:
To answer your comment:
I recommend that you update Puma to version the latest 4.x release (currently 4.3.6). If you can switch to Puma 5.x (currently 5.1) that would be even better. There are bug fixes and improvements all the time. Maybe your issue is related to a solved bug.
If you update to the 5.x version family, you will need to replace the --daemon with a & as mentioned above.
Side Note:
However, I still believe there's an error report you didn't notice of that your toolset failed to log.
I don't know if you looked at the Capistrano logs as well as the Rails / Puma logs and the DigitalOcean server logs.
If you're running Puma with --debug, some Puma messages must appear in the log.
I don't think puma just stops by itself. Maybe it is not running properly as a daemon? I would suggest to figure out what's going on.
That being said, in order to ensure that a certain daemon is always up and running you should use a tool like supervisord: http://supervisord.org/
A cronjob is not the right tool.
I've got a rails 5 application that is very slow after I boot the server or change a .rb file. Below is my cli output after I booted the server with rails server and loaded a simple page. Also, if I change a model, controller or helper, the server takes about the same time to respond to the next request. After the request is loaded, the pages load normally but that first request after each change can take 30 seconds which adds up quite fast. I have tried setting the following configs in `development (similar questions suggested these changes). Also, I have this development server running on a digital ocean droplet with 4GB of memory.
config.assets.debug = false
config.assets.digest = false
My output:
rails server
=> Booting Puma
=> Rails 5.2.2 application starting in development
=> Run rails server -h for more startup options
Puma starting in single mode...
* Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Started GET "/treadmill-parts-model-select" for 98.251.169.224 at 2019-04-03
11:51:29 +0000
Cannot render console from 98.251.169.224! Allowed networks: 127.0.0.1, ::1,
127.0.0.0/127.255.255.255
(2.1ms) SET NAMES utf8, ##SESSION.sql_mode = CONCAT(CONCAT(##sql_mode,
',STRICT_ALL_TABLES'), ',NO_AUTO_VALUE_ON_ZERO'),
##SESSION.sql_auto_is_null = 0, ##SESSION.wait_timeout = 2147483
↳ /usr/local/rvm/gems/ruby-2.5.3/gems/activerecord-
5.2.2/lib/active_record/log_subscriber.rb:98
(2.4ms) SELECT 'schema_migrations'.'version' FROM 'schema_migrations' ORDER
BY 'schema_migrations'.'version' ASC
↳ /usr/local/rvm/gems/ruby-2.5.3/gems/activerecord-
5.2.2/lib/active_record/log_subscriber.rb:98
Processing by SearchController#treadmill_model_search as HTML
Rendering search/treadmill_model_search.html.erb within layouts/application
Product Load (113.8ms) SELECT DISTINCT 'products'.'brand' FROM 'products' WHERE 'products'.'product_type' = 'Treadmill' ORDER BY 'products'.'brand' ASC
↳ app/views/search/treadmill_model_search.html.erb:22
Rendered search/treadmill_model_search.html.erb within layouts/application (167.6ms)
Rendered layouts/_header.html.erb (5.8ms)
Rendered layouts/_flash_messages.html.erb (1.1ms)
Rendered layouts/_footer.html.erb (0.5ms)
Completed 200 OK in 18746ms (Views: 18565.0ms | ActiveRecord: 124.7ms)`
Looks like every time your rails server detects a page change it checks to see if their is a migration pending, which will take some time.
#config/environments/development.rb
config.active_record.migration_error = false
could help with that check.
In the development environment your application's code is reloaded on every request. This slows down response time but is perfect for development since you don't have to restart the web server when you make code changes.
As with larger projects you will want to stop rails from pre-loading all the code which isn't needed especially if you are only working on a portion of your project anyways. Also in the environment
#config/environments/development.rb
# Do not eager load code on boot.
config.eager_load = false
You can read more on these environment config settings here
Though the 4GB of memory seems like a red flag if you aren't working on a massive project... might need to look into your initializes and what all your project is loading up on boot.
A unique identifier is showing before every request output (dev server)
Here an example:
$ rails s
=> Booting Puma
=> Rails 5.0.3 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.10.0 (ruby 2.4.1-p111), codename: Russell's Teapot
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Started GET "/plans" for 127.0.0.1 at 2017-10-17 17:06:48 -0300
[5664e61d-73e6-4ce3-af27-d82aa04abebd] ActiveRecord::SchemaMigration Load (0.6ms) SELECT "schema_migrations".* FROM "schema_migrations"
[5664e61d-73e6-4ce3-af27-d82aa04abebd] DEPRECATION WARNING: before_filter is deprecated and will be removed in Rails 5.1. Use before_action instead. (called from <class:ApplicationController> at /Users/tdonatti/Sites/rails/vmsapi/app/controllers/application_controller.rb:10)
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Processing by PlansController#index as HTML
[5664e61d-73e6-4ce3-af27-d82aa04abebd] User Load (0.4ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2 [["id", 9],
["LIMIT", 1]]
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Plan Load (0.4ms) SELECT "plans"."id", "plans"."title", "plans"."nod", "plans"."price", "plans"."status" FROM "plans"
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Completed 200 OK in 38ms (Views: 9.4ms | ActiveRecord: 7.4ms)
I want to hide this identifier [5664e61d-73e6-4ce3-af27-d82aa04abebd]
I am not sure why and how it shows up but make the output extremely noisy and difficult to track.
In your config file you must have log_tags set to something like
config.log_tags = [ :uuid ]
Remove that and you should be good to go.
Log tags are beneficial for debugging - give this a read when you have time.
I'm getting a Stack Level Too Deep error in my Production environment for spree 2.3.0.
It occurs when I try to go to the product images index page in the Admin panel. This error is not happening in Development, only production on Ninefold. The error does not occur when I run the app locally in Production mode. I can seem to trace what is causing it. I have not changed any of the default core functionality in Spree related to Product Images. The images render fine on the front-end.
I'm using paperclip and aws. At one point there was no error on production. However, I've check all my commits and cant pinpoint what changed that is causing this issue. I've added other gems, but none of the gems conflict with the paperclip gems or its dependency, which was my my guess at what might be causing this.
here is the production log error.
+0000
I, [2015-01-11T22:02:28.691119 #26116] INFO -- : Processing by Spree::Admin::ImagesController#index as HTML
I, [2015-01-11T22:02:28.691252 #26116] INFO -- : Parameters: {"product_id"=>"black-string-tie-halter-top-with-printed-neck-binding"}
D, [2015-01-11T22:02:28.693443 #26116] DEBUG -- : Cache read: spree/app_configuration/redirect_https_to_http
D, [2015-01-11T22:02:28.693920 #26116] DEBUG -- : Cache read: spree/backend_configuration/locale
D, [2015-01-11T22:02:28.695806 #26116] DEBUG -- : [1m[36mSpree::Preference Load (0.7ms)[0m [1mSELECT "spree_preferences".* FROM "spree_preferences" WHERE "spree_preferences"."key" = 'spree/backend_configuration/locale' LIMIT 1[0m
D, [2015-01-11T22:02:28.695979 #26116] DEBUG -- : Cache write: spree/backend_configuration/locale
D, [2015-01-11T22:02:28.696566 #26116] DEBUG -- : Cache read: spree/app_configuration/allow_ssl_in_production
D, [2015-01-11T22:02:28.696881 #26116] DEBUG -- : Cache read: spree/app_configuration/check_for_spree_alerts
D, [2015-01-11T22:02:28.697171 #26116] DEBUG -- : Cache read: spree/app_configuration/last_check_for_spree_alerts
D, [2015-01-11T22:02:28.699099 #26116] DEBUG -- : [1m[35mSpree::User Load (0.5ms)[0m SELECT "spree_users".* FROM "spree_users" WHERE "spree_users"."id" = 1 ORDER BY "spree_users"."id" ASC LIMIT 1
D, [2015-01-11T22:02:28.702026 #26116] DEBUG -- : [1m[36m (0.5ms)[0m [1mSELECT COUNT(*) FROM "spree_roles" INNER JOIN "spree_roles_users" ON "spree_roles"."id" = "spree_roles_users"."role_id" WHERE "spree_roles_users"."user_id" = $1 AND "spree_roles"."name" = 'admin'[0m [["user_id", 1]]
I, [2015-01-11T22:02:28.706068 #26116] INFO -- : Completed 500 Internal Server Error in 15ms
F, [2015-01-11T22:02:28.706732 #26116] FATAL -- :
SystemStackError (stack level too deep):
vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:629
Any help would be greatly appreciated!
update - Full Stack Trace in Production Environment:
SystemStackError in Spree::Admin::ImagesController#index
stack level too deep
Rails.root: /var/www/apps/11829/releases/dbeebbeebaf8ac5fa580e0fd192ad9fc06e7ce4b
Application Trace | Framework Trace | Full Trace
vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:629
So after going through all the gems I installed I finally found the issue.
It was an alias_method in the Spree::Admin::ImagesController decorator that caused the Stack Level Too Deep error.
Somehow this is related but I'm not sure how/why?
Just upgraded from Ruby 1.9.2-p180 to 1.9.2-p290 via RVM's rvm upgrade command...and now my asset pipeline is 'broken'.
During rvm upgrade ... I noticed a bunch of errors for each gemset along lines of:
ERROR: Error running 'rvm gemset pristine' under ,
please read /Users/meltemi/.rvm/log//gemset.pristine.log
I let upgrade continue as there was not much interesting in the gemset.pristine.log... besides, /Users/meltemi/.rvm/log//gemset.pristine.log doesn't (can't?) exist in that exact path? two consecutive '//' in a pathname? Anyway...
Testing a small app and though it launches and appears to run it is not loading any assets (images, css, etc.). Development log has many Not Found errors (see below) about these missing assets even though they exist within app/assets/images and app/assets/stylesheets, etc... ?
Anyone know what's happening here? Seems like pipeline has broken down somehow... As if Rails no longer knows to look for assets in app/assets, perhaps? How can I test/verify/fix/re-activate this 'pipeline'?
$ rails s
=> Booting WEBrick
=> Rails 3.1.0.rc4 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-07-25 23:11:38] INFO WEBrick 1.3.1
[2011-07-25 23:11:38] INFO ruby 1.9.2 (2011-07-09) [x86_64-darwin10.8.0]
[2011-07-25 23:11:38] INFO WEBrick::HTTPServer#start: pid=74881 port=3000
Started GET "/" for 127.0.0.1 at 2011-07-25 23:11:43 -0700
Processing by PostsController#index as HTML
Post Load (0.2ms) SELECT "posts".* FROM "posts" ORDER BY posts.created_at DESC
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.3ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 6
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 5
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 4
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 2
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 1
Rendered posts/index.html.haml within layouts/application (3016.4ms)
Rendered layouts/_header.html.haml (9.7ms)
Completed 200 OK in 3143ms (Views: 3138.2ms | ActiveRecord: 2.9ms)
Started GET "/assets/application.css" for 127.0.0.1 at 2011-07-25 23:11:47 -0700
Served asset /application.css - 404 Not Found (1ms)
ActionController::RoutingError (No route matches [GET] "/assets/application.css"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (1.2ms)
Started GET "/assets/application.js" for 127.0.0.1 at 2011-07-25 23:11:47 -0700
Served asset /application.js - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/application.js"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (0.8ms)
Started GET "/assets/racer-outline.png" for 127.0.0.1 at 2011-07-25 23:11:48 -0700
Served asset /racer-outline.png - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/racer-outline.png"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (3.2ms)
Started GET "/assets/ray.png" for 127.0.0.1 at 2011-07-25 23:11:48 -0700
Served asset /pogo.png - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/ray.png"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (1.2ms)
It seems that version 2.0.0.beta.11 of sprockets broke the assets pipeline. Putting
gem 'sprockets', '= 2.0.0.beta.10'
into your Gemfile seems to fix the problem (it worked for me). Rails seems to automatically use the most recent version of the beta for whatever reason so if you just started your project recently or updated all your gems it probably broke it.
Note that this info isn't mine originally, I got the fix from http://groups.google.com/group/rubyonrails-core/browse_thread/thread/59d8c7813b4d1bbe?pli=1
He explains the problem for ver. 2.0.0.beta.11 but I was using ver. 2.0.0.beta.12 with the same results so it seems that they haven't fixed it yet.
EDIT: It seems that upgrading your rails to 3.1.rc5 also fixes the problem
I ended up just blowing out the whole problematic gemset and starting anew. Lesson learned:
Don't trust rvm upgrade. Install the new Ruby w/in RVM. Then manually rebuild (or bundle install) your gemsets.