I have a fairly simple Tweetstream listener built in a Sinatra app that I am trying to get running on Heroku. It gets up and running fine, but after about a minute I get the following error:
2012-12-04T06:23:31+00:00 heroku[web.1]: Stopping process with SIGKILL
2012-12-04T06:23:31+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
Here is, basically, what I'm running:
require 'sinatra'
client = TwitterListener.new
puts "starting Twitter listener..."
client.restart
require 'tweetstream'
class TwitterListener
def initialize
#client = TweetStream::Client.new
...
#events = Events.new
end
def restart
...
#client.follow(users) do |status|
#events.mention_artist?(status, artists)
#events.retweet_artist?(status, artists)
end
end
end
It's starting the streaming listener and if I tweet fast enough, it picks it up, but Heroku seems to time out during the tweetstream loop. How can I fix this?
So I manged to work this out myself.
When running something a long running process like Tweetstream (which uses Eventmachine, I believe) on Heroku, you must use a worker dyno. The web dyno with time out if a process doesn't complete in 60 seconds. That's why I was getting the R10 timeout error.
To change to a worker dyno I needed to adjust my Procfile from
web: bundle exec rackup config.ru -p $PORT
to
worker: bundle exec rackup config.ru -p $PORT
And then turn off the web process and turn on a worker process named 'worker'
> heroku ps:scale web=0 worker=1
Because I only need one dyno working at this point in the project.
Related
I'm trying to execute a ruby daemon framework-less app on Heroku, but it crash after trying to execute the worker:
heroku[worker.1]: State changed from crashed to starting
heroku[worker.1]: Starting process with command `bundle exec rake twitter:start`
heroku[worker.1]: State changed from starting to up
heroku[worker.1]: Process exited with status 0
heroku[worker.1]: State changed from up to crashed
The app basically collects data, through a bunch of APIs, and saves it on a remote MongoHQ instance.
The rake tasks are:
dir_path = File.expand_path('../', __FILE__)
namespace :twitter do
desc 'Start Twitter daemon'
task :start do
exec "#{dir_path}/bin/autana start"
end
...
end
The Procfile is very simple: worker: bundle exec rake twitter:start
The code that executes the daemon is the following:
#!/usr/bin/env ruby
require 'daemons'
require File.expand_path('../../lib/autana', __FILE__)
Daemons.run_proc('autana', multiple: true, no_pidfiles: true) do
client = Autana::Client::Twitter.new
client.collect
end
Any ideas?
Can you run it dynamically?
heroku run rake twitter:start
So, it was a MongoDB error. Data was not properly associated. After entering the console, and changed the document, everything worked as expected.
I followed heroku's instructions on deploying a Sinatra application carefully but something is still going wrong. I am using sinatra-base and sinatra-partial if that makes any difference. I have all the gems declared in the gemfile and myapp.rb
Gist of my files
This is what I see on heroku logs
2013-06-11T05:09:28.982664+00:00 app[web.1]: from myapp.rb:49:in `<class:MyApp>'
2013-06-11T05:09:29.148291+00:00 app[web.1]: [2013-06-11 05:09:29] INFO WEBrick 1.3.1
2013-06-11T05:09:29.148613+00:00 app[web.1]: == Sinatra/1.4.0 has taken the stage on 4567 for production with backup from WEBrick
2013-06-11T05:09:29.148759+00:00 app[web.1]: [2013-06-11 05:09:29] INFO WEBrick::HTTPServer#start: pid=2 port=4567
2013-06-11T05:09:29.148291+00:00 app[web.1]: [2013-06-11 05:09:29] INFO ruby 1.9.2 (2011-07-09) [x86_64-linux]
2013-06-11T05:10:26.570140+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2013-06-11T05:10:26.570414+00:00 heroku[web.1]: Stopping process with SIGKILL
2013-06-11T05:10:28.018692+00:00 heroku[web.1]: Process exited with status 137
2013-06-11T05:10:28.033080+00:00 heroku[web.1]: State changed from starting to crashed
After doing a bit more research on the Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch error, it may be because of gems taking a long time to load. However, I am only using these gems so I don't know why it's timing out. Locally, it takes about 1 second to start up my application.
Heroku dynamically assigns the port. You are starting the app on port 4567 when you call the run! method in lines 85-97 of myapp.rb. You should be able to remove those three lines and use config.ru to start your app.
It you add the heroku gem to your Gemfile, you can remove the Procfile. Otherwise you should cahnge it start the app via backup:
web: bundle exec rackup config.ru -p $PORT
You could also add 'thin' to your Gemfile and use a Procfile like this
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
I am trying to load a simple ruby app on heroku that periodically runs a background task using resque, which checks an email account. It works fine locally with foreman, but keeps crashing on heroku.
I think maybe the Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch comes from my while loop, which is perpetual and therefore longer than 60 seconds? Should I be using some different kind of process to launch smsnotify.rb?
Any help would be extremely appreciated!
My heroku logs:
2013-04-06T20:49:15+00:00 heroku[slugc]: Slug compilation finished
2013-04-06T20:49:18+00:00 heroku[web.1]: Starting process with command `bundle exec ruby smsnotify.rb -p 9129`
2013-04-06T20:49:21+00:00 app[web.1]: /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.0.0/lib/active_support/multibyte.rb:26: warning: already initialized constant VALID_CHARACTER
2013-04-06T20:50:19+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2013-04-06T20:50:19+00:00 heroku[web.1]: Stopping process with SIGKILL
2013-04-06T20:50:20+00:00 heroku[web.1]: Process exited with status 137
2013-04-06T20:50:20+00:00 heroku[web.1]: State changed from starting to crashed
My Procfile:
web: bundle exec ruby smsnotify.rb -p $PORT
resque: env TERM_CHILD=1 bundle exec rake jobs:work
smsnotify.rb:
require "./email_checker"
require 'hirefire'
require 'resque'
Resque.redis = 'redis://redistogo:removed:removed/'
HireFire::Initializer.initialize!
while true do
Resque.enqueue(EmailChecker)
sleep 30
puts "Starting Email Job"
end
You aren't starting up a process that is binding to a port, so it is complaining.
You just need to change your Procfile to say 'worker' instead of 'web'
If you have a web frontend to this, then you will need a worker and a web
Every time I launch my app it cannot get past the 60 second point without:
2012-05-06T22:41:11+00:00 heroku[web.1]: Stopping process with SIGKILL
2012-05-06T22:41:11+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2012-05-06T22:41:11+00:00 heroku[web.1]: Process exited with status 137
2012-05-06T22:41:12+00:00 heroku[web.1]: State changed from starting to crashed
Here is my Procfile:
web: bundle exec thin start -p $PORT
Any responses will be thoroughly appreciated.
If your app does take longer than 60 seconds for "good" reasons, you can work around the 60s boot time limit with https://github.com/dblock/heroku-forward.
The solution was that I had forgotten to include the -p $PORT in my Procfile line.
in Procfile change:
web: bundle exec thin start
to
web: bundle exec thin start -p $PORT
That fixed it for me.
Heroku's boot timeout bit me too. I read several blog posts about how to get around it and ended up automating some of the solutions into a gem.
To reduce the startup time on deploy, you can trim the gems loaded at boot time (this doesn't mean you have to trim them from the app, just boot time).
gem_bench evaluates which gems are likely to not be needed at boot time.
I have an app with about 250 gems and was able to add :require => false to about 60 of them, with dramatic effects.
https://github.com/acquaintable/gem_bench
Disclaimer: I am the author of this open source ruby gem. I wrote the gem to aid myself in solving this exact problem: the 60 second timeout on Heroku.
Hi i was facing the same issue.I have resolved this issue by increase the timeout in /config/unicorn.rb
change timeout 15 to timeout 20 in /config/unicorn.rb
In my case using nodejs I solved this adding a Procfile file with content:
worker: node index.js and push it to heroku.
After that make sure to disable the check "web npm start" and turn on the check "worker node index.js" just like the image attached below
herokuResourcesConfig
I was having the same error when deploying my Node app on Heroku.
I got it solved by adding a Procfile.
web: node app.js
It tells Heroku how to start the application.
The error is because of Heroku is not able to configure on which PORT to run the application.
It can be solved by specifying the PORT for Heroku, ie: in app.js
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
console.log(`App is running on port ${ PORT }`);
});
Error R10 (Boot timeout)
is this hidden section of heroku allows you to increase the deployment time.
https://tools.heroku.support/limits/boot_timeout
I got this error because Heroku didn't have access to the Mongo Atlas database. You need to change this in the database settings
have the same issue, solved by creating file with proxy server
https://www.npmjs.com/package/http-proxy#setup-a-basic-stand-alone-proxy-server
proxy.js:
httpProxy.createProxyServer({
target, // target that can't cant be exposed, e.g. localhost:4000
changeOrigin: true,
}).listen(process.env.PORT); // port from heroku runtime
then
node server/proxy.js
I'm using HireFireApp to autoscale my web and worker dynos on Heroku. However, when I navigate to the Resque app on my application it says
"0 of 46 Workers Working"
Does this mean that I'm using 46 worker dynos???
Update:
Running heroku ps shows:
web.1 up for 21m bundle exec thin start -p $PORT
worker.1 starting for 1s bundle exec rake resque:work QUEUE..
From the command line in your heroku app have a look at the output of
heroku ps
that will show you how many workers you are running.