I have been looking at my Heroku logs and I just can't figure out why my woker is not functioning. It works locally and when I do heroku run rake perform_later I get a response that my job is enqueued
Heroku logs
2016-02-09T20:02:04.364227+00:00 heroku[scheduler.2066]: State changed from up to complete
2016-02-09T20:02:04.350705+00:00 heroku[scheduler.2066]: Process exited with status 0
2016-02-09T21:00:57.182878+00:00 heroku[api]: Starting process with command `bundle exec rake perform_later` by scheduler#addons.heroku.com
2016-02-09T21:01:04.063903+00:00 heroku[scheduler.9121]: Starting process with command `bundle exec rake perform_later`
2016-02-09T21:01:04.681867+00:00 heroku[scheduler.9121]: State changed from starting to up
2016-02-09T21:01:07.923640+00:00 app[scheduler.9121]: [Simple Form] Simple Form is not configured in the application and will use the default values. Use `rails generate simple_form:install` to generate the Simple Form configuration.
2016-02-09T21:01:07.965160+00:00 app[scheduler.9121]: [ActiveJob] Enqueued GettweetsJob (Job ID: d3363b17-a2f9-4ffd-85b7-a5188b89605d) to Sidekiq(default)
2016-02-09T21:01:08.614883+00:00 heroku[scheduler.9121]: Process exited with status 0
2016-02-09T21:01:08.611923+00:00 heroku[scheduler.9121]: State changed from up to complete
2016-02-09T21:24:48.087768+00:00 heroku[web.1]: State changed from down to starting
2016-02-09T21:24:48.087325+00:00 heroku[web.1]: Unidling
2016-02-09T21:24:51.847314+00:00 heroku[web.1]: Starting process with command `bundle exec puma -C config/puma.rb`
2016-02-09T21:24:53.513605+00:00 app[web.1]: [3] Puma starting in cluster mode...
2016-02-09T21:24:53.513625+00:00 app[web.1]: [3] * Version 2.15.3 (ruby 2.2.3-p173), codename: Autumn Arbor Airbrush
2016-02-09T21:24:53.513627+00:00 app[web.1]: [3] * Environment: production
2016-02-09T21:24:53.513663+00:00 app[web.1]: [3] * Preloading application
2016-02-09T21:24:53.513626+00:00 app[web.1]: [3] * Min threads: 3, max threads: 3
2016-02-09T21:24:53.513628+00:00 app[web.1]: [3] * Process workers: 2
2016-02-09T21:24:55.539022+00:00 app[web.1]: [3] * Listening on tcp://0.0.0.0:23385
2016-02-09T21:24:55.539160+00:00 app[web.1]: [3] Use Ctrl-C to stop
2016-02-09T21:24:55.544071+00:00 app[web.1]: [3] - Worker 0 (pid: 6) booted, phase: 0
2016-02-09T21:24:55.520328+00:00 app[web.1]: [Simple Form] Simple Form is not configured in the application and will use the default values. Use `rails generate simple_form:install` to generate the Simple Form configuration.
2016-02-09T21:24:55.545450+00:00 app[web.1]: [3] - Worker 1 (pid: 10) booted, phase: 0
2016-02-09T21:24:56.075839+00:00 heroku[web.1]: State changed from starting to up
Job
class GettweetsJob < ActiveJob::Base
queue_as :default
def perform(*args)
client = Twitter::REST::Client.new do |config|
config.consumer_key = "aaaa"
config.consumer_secret = "bbbb"
config.access_token = "cccc"
config.access_token_secret = "dddd"
end
client.mentions_timeline.each do |tweet|
Tweet.create({text: tweet.text, username: tweet.user.screen_name})
end
end
end
rake task
desc "This task is called by the Heroku scheduler add-on"
task :perform_later => :environment do
GettweetsJob.perform_later
end
response heroku run rake perform_later
[Simple Form] Simple Form is not configured in the application and will use the default values. Use `rails generate simple_form:install` to generate the Simple Form configuration.
[ActiveJob] Enqueued GettweetsJob (Job ID: 5f71c5e3-f2f3-4c5d-8396-1eb5cb25068b) to Sidekiq(default)
procfile
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq -C config/sidekiq.yml
sidekiq.yml
:concurrency: 3
:timeout: 60
:verbose: true
:queues:
- default
- mailers
Related
I have a new, Rails 6 app that I'm trying to deploy to Heroku.
Judging from the deploy log and the logs I'm getting with heroku logs --tail everything seems to work, but when I go to the deployed, herokuapp.com domain, I get the 'No such app' screen.
Here is the latest logs:
2021-11-19T13:45:11.000000+00:00 app[api]: Build succeeded
2021-11-19T13:45:11.060793+00:00 heroku[web.1]: Starting process with command `bundle exec puma -C config/puma.rb`
2021-11-19T13:45:12.126085+00:00 app[web.1]: [4] Puma starting in cluster mode...
2021-11-19T13:45:12.126103+00:00 app[web.1]: [4] * Puma version: 5.5.2 (ruby 3.0.2-p107) ("Zawgyi")
2021-11-19T13:45:12.126103+00:00 app[web.1]: [4] * Min threads: 5
2021-11-19T13:45:12.126104+00:00 app[web.1]: [4] * Max threads: 5
2021-11-19T13:45:12.126104+00:00 app[web.1]: [4] * Environment: production
2021-11-19T13:45:12.126104+00:00 app[web.1]: [4] * Master PID: 4
2021-11-19T13:45:12.126104+00:00 app[web.1]: [4] * Workers: 2
2021-11-19T13:45:12.126127+00:00 app[web.1]: [4] * Restarts: (✔) hot (✖) phased
2021-11-19T13:45:12.126133+00:00 app[web.1]: [4] * Preloading application
2021-11-19T13:45:13.203269+00:00 app[web.1]: [4] * Listening on http://0.0.0.0:54150
2021-11-19T13:45:13.203334+00:00 app[web.1]: [4] Use Ctrl-C to stop
2021-11-19T13:45:13.207647+00:00 app[web.1]: [4] - Worker 0 (PID: 7) booted in 0.0s, phase: 0
2021-11-19T13:45:13.209455+00:00 app[web.1]: [4] - Worker 1 (PID: 9) booted in 0.0s, phase: 0
2021-11-19T13:45:13.336382+00:00 heroku[web.1]: State changed from starting to up
And here's the puma config:
workers Integer(ENV['WEB_CONCURRENCY'] || 2)
threads_count = Integer(ENV['RAILS_MAX_THREADS'] || 5)
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 3000
environment ENV['RACK_ENV'] || 'development'
on_worker_boot do
# Worker specific setup for Rails 4.1+
# See: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#on-worker-boot
ActiveRecord::Base.establish_connection
end
Which is the one recommended by Heroku in their documentation.
The Procfile is a simple one-liner:
web: bundle exec puma -C config/puma.rb
I also tried the heroku configuration by running PORT=3000 heroku local on my machine and it works wonderfully, but not on Heroku's platform :(
I'm using Rails 6.1.4.1 and ruby 3.0.2
Can you point me at where I could try to find the root of the problem?
Thank you,
Balint
This seems to have been a transient issue. When I came back to the problem a few hours later, it just worked without me having to change anything.
Rails 5.2
redis 4.0.1
sidekiq 5.1.3
RedisToGo on Heroku
Proc File:
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq -e production -C config/sidekiq.yml
sidekiq.yml
development:
:concurrency: 5
production:
:concurrency: 6
:queues:
- default
config/initialize/sidekiq.rb
if Rails.env.production?
Sidekiq.configure_client do |config|
config.redis = { url: ENV['REDISTOGO_URL'] || ENV['REDIS_URL'], size: 1 }
end
Sidekiq.configure_server do |config|
pool_size = ENV['SIDEKIQ_DB_POOL'] || (Sidekiq.options[:concurrency] + 2)
config.redis = { url: ENV['REDISTOGO_URL'] || ENV['REDIS_URL'], size: pool_size }
Rails.application.config.after_initialize do
Rails.logger.info("DB Connection Pool size for Sidekiq Server before disconnect is: #{ActiveRecord::Base.connection.pool.instance_variable_get('#size')}")
ActiveRecord::Base.connection_pool.disconnect!
ActiveSupport.on_load(:active_record) do
db_config = Rails.application.config.database_configuration[Rails.env]
db_config['reaping_frequency'] = ENV['DATABASE_REAP_FREQ'] || 10 # seconds
db_config['pool'] = pool_size
ActiveRecord::Base.establish_connection(db_config)
Rails.logger.info("DB Connection Pool size for Sidekiq Server is now: #{ActiveRecord::Base.connection.pool.instance_variable_get('#size')}")
end
end
end
end
I have no idea why the job is stuck in the queue. The job works on my local in development.
Any assistance appreciated.
Update!
As per the comment here is the output of heroku ps:
=== web (Free): bundle exec puma -C config/puma.rb (1)
web.1: up 2018/06/15 18:49:56 +0700 (~ 5s ago)
=== worker (Free): bundle exec sidekiq -q default (1)
worker.1: crashed 2018/06/15 18:49:51 +0700 (~ 10s ago)
Seems a worker crashed for some reason.
Heroku logs:
2018-06-15T11:56:00.301716+00:00 app[web.1]: [4] Puma starting in cluster mode...
2018-06-15T11:56:00.301740+00:00 app[web.1]: [4] * Version 3.11.2 (ruby 2.4.1-p111), codename: Love Song
2018-06-15T11:56:00.301760+00:00 app[web.1]: [4] * Min threads: 5, max threads: 5
2018-06-15T11:56:00.301794+00:00 app[web.1]: [4] * Environment: production
2018-06-15T11:56:00.301801+00:00 app[web.1]: [4] * Process workers: 2
2018-06-15T11:56:00.301838+00:00 app[web.1]: [4] * Preloading application
2018-06-15T11:56:01.249511+00:00 app[worker.1]: DB Connection Pool size for Sidekiq Server before disconnect is: 5
2018-06-15T11:56:01.252654+00:00 app[worker.1]: could not connect to server: No such file or directory
2018-06-15T11:56:01.252657+00:00 app[worker.1]: Is the server running locally and accepting
2018-06-15T11:56:01.252659+00:00 app[worker.1]: connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
After talking with tech support at Heroku it turns out that I needed to change the way I had my db yaml file coded.
I changed it to the following:
production:
url: <%= ENV['DATABASE_URL'] %>
That seem to solve the issue.
Install Heroku Postgres as an addon and then add the environment variables to your project and everything should work fine. - https://elements.heroku.com/addons/heroku-postgresql
I'm trying to make a little library that wraps over march_hare and is used as part of our Rails app. It needs to connect on app startup and disconnect on shutdown.
I'am aiming to something similar to the ruby-kafka Rails integration via initializer:
configure my service
run it
specify shutdown procedure
The problem is my at_exit blocks are sometimes not executed. What may be the cause of this issue? Is there a way to fix it and ensure my at_exit blocks are called?
Investigating the issue, I created a blank demo app with the following initializer:
class SomeClass
def self.shutdown(reason)
msg = "#{Time.now} SHUTDOWN via #{reason}!"
puts msg
open('log/development.log', 'a') do |f|
f.puts msg
end
end
end
at_exit { SomeClass.shutdown(:at_exit1) }
at_exit { SomeClass.shutdown(:at_exit2) }
at_exit { SomeClass.shutdown(:at_exit3) }
puts "#{Time.now} INITIALIZED!"
In 9 out of 10 run + terminate cycles I get:
$ rails s
=> Booting Puma
=> Rails 4.2.7.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
2017-05-22 15:29:16 +0300 INITIALIZED!
Puma starting in single mode...
* Version 3.4.0 (jruby 9.1.2.0 - ruby 2.3.0), codename: Owl Bowl Brawl
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
^C- Gracefully stopping, waiting for requests to finish
Exiting
=== puma shutdown: 2017-05-22 15:29:30 +0300 ===
- Goodbye!
2017-05-22 15:29:30 +0300 SHUTDOWN via at_exit3!
2017-05-22 15:29:30 +0300 SHUTDOWN via at_exit2!
2017-05-22 15:29:30 +0300 SHUTDOWN via at_exit1!
But once in a while the result is:
$ rails s
=> Booting Puma
=> Rails 4.2.7.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
2017-05-22 15:29:45 +0300 INITIALIZED!
Puma starting in single mode...
* Version 3.4.0 (jruby 9.1.2.0 - ruby 2.3.0), codename: Owl Bowl Brawl
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
^C- Gracefully stopping, waiting for requests to finish
Exiting
=== puma shutdown: 2017-05-22 15:30:17 +0300 ===
- Goodbye!
2017-05-22 15:30:17 +0300 SHUTDOWN via at_exit2!
2017-05-22 15:30:17 +0300 SHUTDOWN via at_exit1!
My Gemfile has only gem 'puma' added.
Ruby version: jruby 9.1.2.0
Rails version: Rails 4.2.7.1
System Version: macOS 10.12.4
This is something to do with JRuby. You could try upgrading JRuby to the latest version and see if that's fixed.
Else follow this thread for more reference.
https://github.com/jruby/jruby/issues/5437
I've been trying everything I can find online, and nothing is working. Hoping some fresh eyes will see the issue. This is my first time using ActionCable, and everything works great locally, but when pushing to heroku. my logs do not show any actioncable subscriptions like my dev server:
[ActionCable] [email#email.com] MsgsChannel is streaming from msg_channel_34
and when sending a message, I do see [ActionCable] Broadcasting to msg_channel_34: but they are not appending, which I'm guessing means that the received method is not being accessed/called?
I do notice on heroku's logs it says Listening on tcp://0.0.0.0:5000 where as dev it is listening at localhost:3000. Should I be pointnig towards my heroku app somehow?
Here are the relevant configuration files:
Procfile:
web: bundle exec puma -p 5000 ./config.ru
actioncable: bundle exec puma -p 28080 cable/config.ru
redis: redis-server
***Thanks to the comment below, I am also trying. Still not working, but I can see that the port it's listening to is changing, making me believe it has something to do with the configuration? :
web: bundle exec puma -p $PORT ./config.ru
actioncable: bundle exec puma -p $PORT cable/config.ru
redis: redis-server
/cable/config.ru
require ::File.expand_path('../../config/environment', __FILE__)
Rails.application.eager_load!
ActionCable.server.config.allowed_request_origins = ["http://localhost:3000"]
run ActionCable.server
config/environments/development.rb
config.action_cable.allowed_request_origins = ['localhost:3000']
config.action_cable.url = "ws://localhost:3000/cable"
config/environments/production.rb
config.web_socket_server_url = "wss://app-name.herokuapp.com/cable"
config.action_cable.allowed_request_origins = ['https://app-name.herokuapp.com', 'http://app-name.herokuapp.com']
config/cable.yml
local: &local
adapter: async
:url: redis://localhost:6379
:host: localhost
:port: 6379
:timeout: 1
:inline: true
development: *local
test: *local
production:
:url: redis:<%= ENV["REDISTOGO_URL"] %>
adapter: redis
<%= ENV["REDISTOGO_URL"] %> is set, confirmed by running heroku config
routes.rb
mount ActionCable.server => '/cable'
Why is this working on dev, but not on heroku? I've been reading for hours, but can not figure it out. Thank you!!
UPDATE:
heroku logs:
2017-01-25T20:32:57.329656+00:00 heroku[web.1]: Starting process with command `bundle exec puma -p 5000 ./config.ru`
2017-01-25T20:32:59.600554+00:00 app[web.1]: Puma starting in single mode...
2017-01-25T20:32:59.600574+00:00 app[web.1]: * Version 3.6.2 (ruby 2.3.1-p112), codename: Sleepy Sunday Serenity
2017-01-25T20:32:59.600575+00:00 app[web.1]: * Min threads: 0, max threads: 16
2017-01-25T20:32:59.600577+00:00 app[web.1]: * Environment: production
2017-01-25T20:33:02.375128+00:00 app[web.1]: profile controller
2017-01-25T20:33:02.588653+00:00 app[web.1]: Use Ctrl-C to stop
2017-01-25T20:33:02.588446+00:00 app[web.1]: * Listening on tcp://0.0.0.0:5000
2017-01-25T20:33:17.681469+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2017-01-25T20:33:17.681469+00:00 heroku[web.1]: Stopping process with SIGKILL
2017-01-25T20:33:17.862118+00:00 heroku[web.1]: Process exited with status 137
2017-01-25T20:33:57.501746+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2017-01-25T20:33:57.501908+00:00 heroku[web.1]: Stopping process with SIGKILL
2017-01-25T20:33:57.630071+00:00 heroku[web.1]: Process exited with status 137
2017-01-25T20:33:57.642753+00:00 heroku[web.1]: State changed from starting to crashed
The issue was my host is the heroku app, but the requests were coming from the custom domain.
To solve:
heroku config:set RAILS_HOST "http://www.example.com"
And then in production.rb:
config.action_cable.url = "wss://#{ENV['RAILS_HOST']}/cable"
Is your app name literally app-name? I suspect not. Odds are pretty good that these values...
config.web_socket_server_url = "wss://app-name.herokuapp.com/cable"
config.action_cable.allowed_request_origins = ['https://app-name.herokuapp.com', 'http://app-name.herokuapp.com']
Need to be updated to use the actual public-facing URL you intend to connect to.
Your procfile suggests that you run puma with cable/cable.ru on port 28080. Also - file cable/config.ru shouldn't contain this line:
ActionCable.server.config.allowed_request_origins = ["http://localhost:3000"]
You already configured this in config/environment/*.rb
I had the same issue, and found the answer I needed here: redis gem 4+ incompatibility "Specified 'redis' for Action Cable pubsub adapter, but the gem is not loaded". Once I downgraded my redis to 3.1.0, worked perfectly.
I'm running a rails app on heroku, I have two web dynos.
How can I remove the ! WARNING: Detected 1 Thread(s) started in app boot: warning?
My puma.rb file:
workers Integer(ENV['WEB_CONCURRENCY'] || 2)
threads_count = Integer(ENV['RAILS_MAX_THREADS'] || 5)
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 3000
environment ENV['RACK_ENV'] || 'development'
on_worker_boot do |worker_number|
# Worker specific setup for Rails 4.1+
# See: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#on-worker-boot
ActiveRecord::Base.establish_connection
end
The logs:
2016-09-03T14:21:24.742960+00:00 app[web.1]: [3] * Listening on tcp://0.0.0.0:53786
2016-09-03T14:21:24.743135+00:00 app[web.1]: [3] ! WARNING: Detected 1 Thread(s) started in app boot:
2016-09-03T14:21:24.743181+00:00 app[web.1]: [3] ! #<Thread:0x007f382b59fca8#/app/vendor/bundle/ruby/2.2.0/gems/rufus-scheduler-3.2.2/lib/rufus/scheduler.rb:563 sleep> - /app/vendor/bundle/ruby/2.2.0/gems/rufus-scheduler-3.2.2/lib/rufus/scheduler.rb:571:in `sleep'
2016-09-03T14:21:24.743257+00:00 app[web.1]: [3] Use Ctrl-C to stop
2016-09-03T14:21:24.754941+00:00 app[web.1]: [3] - Worker 0 (pid: 7) booted, phase: 0
2016-09-03T14:21:24.756269+00:00 app[web.1]: [3] - Worker 1 (pid: 20) booted, phase: 0
2016-09-03T14:21:25.525174+00:00 app[web.2]: ** [NewRelic][2016-09-03 14:21:25 +0000 web.2 (18)] INFO : Doing deferred dependency-detection before Rack startup
It's very easy. Stop using rufus-scheduler. It's using threads, that's what is causing your warning.
Look at:
2016-09-03T14:21:24.743181+00:00 app[web.1]: [3] !
<Thread:0x007f382b59fca8#
/app/vendor/bundle/ruby/2.2.0/gems/rufus-scheduler-3.2.2/lib/rufus/scheduler.rb:563
sleep> -
/app/vendor/bundle/ruby/2.2.0/gems/rufus-scheduler-3.2.2/lib/rufus/scheduler.rb:571
:in `sleep'
Rufus-scheduler clearly is the cause of the warning.
Cf https://github.com/jmettraux/rufus-scheduler/issues/213
Now there is another way to look at the thing: the warning is not emitted by rufus-scheduler, it's emitted by Puma. There's probably a way to disable the warning, but that's a question for people with knowledge of Puma.