My Heroku worker keeps on crashing whenver I do restart it crashes within 5 seconds.
Below is my Procfile:
resque: env TERM_CHILD=1 bundle exec rake resque:work
resque: env TERM_CHILD=1 RESQUE_TERM_TIMEOUT=7 bundle exec rake resque:work
I'm trying to get Resque work on the system but also unsure that if Resque process even started on the server. Locally I would do:
rake resque:work QUEUE=* and this work work perfectly.
Is there a reason why my Worker Dyno keeps on crashing also a way to check if resque is running successfully?
You can type:
heroku ps
Which will tell you what processes are running at any given time.
heroku logs
That will obviously give you detailed information about what's happening. Copy in your log file and I bet someone will be able to fix it for you. My guess is you're seeing a does not exist error in there somewhere, which is something I ran into :)
Related
I'm trying to run heroku CLI commands like:
heroku run rake db:migrate --app app-name
heroku run rake db:seed --app app-name
from a Resque worker running in the background.
If I run the worker in the foreground with:
RAILS_ENV=production rake resque:work QUEUE="*"
the process completes successfully, and the rake tasks are run.
However, when the worker is started like so:
RAILS_ENV=production PIDFILE=./resque.pid BACKGROUND=yes QUEUE="*" rake resque:work >> worker1.log
the processes silently fail with no indication of what happened in the logs. Is there a way to run these tasks in the background?
Like max said I'm not sure why you would want to do this, but if you want to invoke a Rake task from a Ruby script, in your case it is better to actually load the Rake task into memory and run it from within your Resque worker. Here is a SO answer that explains how to run a Rake task from Ruby: https://stackoverflow.com/a/15259172/586983
Whenever I run heroku run bundle exec sidekiq, I see all my background jobs being done, however, I want them to be able to go without me needing to be there. When I exit out of that terminal tab, sidekiq stops working. How would I mitigate that?
Also, I've read something about procfiles and increasing workers. I don't know what procfiles are and I don't know how to increase workers either.
Basically, I'm a newbie trying to get sidekiq set up to run on Heroku for my Rails app. I want it to be running at all times.
Create a file named ./Procfile with the following in it:
web: bundle exec rails server -p $PORT
worker: bundle exec sidekiq
sidekiq on Heroku
more on Procfiles
foreman gem
I have a script which in need to run on my data. I have made a rake task for that. If i start the rake task by using heroku run rake my_task:my_action and after a while my internet disconnects. What would happen. Will the task continue to run as it has been initiated on a remote machine. I think it will continue to run. Any ideas.
Processes started in a one-off dyno (the kind of dyno that is provisioned with heroku run command) run attached to your local terminal and will terminate if your internet disconnects or you cancel the command locally.
To execute a process in a one-off dyno that is not attached to your local terminal, use heroku run:detached:
$ heroku run:detached bundle exec rake my_task:my_action
Running `bundle exec rake my_task:my_action` detached... up, run.7562
Use `heroku logs -p run.7562` to view the output.
To introspect whether the one-off dyno is still running use heroku ps. One-off dynos are named run.X where X is some number.
Guys so after trying and exploring i have found that in normal circumstances it doesnt continue. When the terminal closes pipes breaks and it stops to continue.
You can run your rake in screen to prevent your script/rake from breaking if you get disconnected.
http://www.gnu.org/software/screen/manual/screen.html
New to Rails and very new to Delayed Jobs.
Got one that's supposed to be triggered after 5 minutes. I finally got it to work so that if I run
rake jobs:work
in my terminal, the job starts up and works correctly. If I CTRL-C and exit that action in my terminal, the delayed job stops working correctly. This is one thing on my local server and another on Heroku, where I have to start up the delayed job using
heroku run rake jobs:work
I looked into the new Heroku toolbelt and downloaded the gem they suggest for worker maintenance, foreman, but when I run "foreman start", I get this error
ERROR: procfile does not exist
I don't know what a procfile is, I'm afraid of breaking things after spending pretty much a day debugging my delayed_jobs actions, and I want to do this right to make sure it works instead of figuring out some hacky fix that breaks down later -- so I figured I should ask this question, however obnoxiously vague it may be.
Should I be using foreman for this? Or workless? (Saw that in another SO question). Where's my procfile? Should I do anything with it?
Thanks,
Sasha
You should be using a procfile to set up your Heroku processes, this is the standard method that Heroku uses to define and control the processes.
If you haven't utilised a procfile to this point everything will probably still work as Heroku adds some default processes when you push a Rails app, including both the web and worker processes. The default worker process is set to delayed job.
Foreman was developed in order to set up your local machine to use the same approach but, unlike the Heroku service, Foreman actually requires a procfile to be present to control the services that are started when Foreman is started as it doesn't know how to setup defaults.
I would suggest creating a procfile, placed in the root directory of your project, to ensure that your processes are set up and operating in the same manner on your local machine as on Heroku. If you want to mimic what Heroku sets up automatically you add the following to the procfile depending on whether you are using the Thin web server (which Heroku recommends) or not.
With Thin in your gemfile:
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
worker: bundle exec rake jobs:work
Without a special web server (eg you are using webrick, the rails default):
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
Once this file is in place you can run foreman on your local machine and it will start your web server and delayed_job workers automatically.
Running through this process will only impact starting delayed_job on the local machine. As you are running the exact same command bundle exec rake jobs:work as you are currently using there should be no impact on your dj actions in either locally or on Heroku. Obviously some testing is required to make suer this is actually the case.
Workless is designed to scale workers on Heroku so that you don't have to pay for them when there is no work available. It has no bearing on the procfile or defining how to actually start a dj worker process.
as far as I know, there are 2 version of delayed_job:
original(tobi's) https://github.com/tobi/delayed_job
collectiveidea's fork: https://github.com/collectiveidea/delayed_job
when using the collectiveidea version, you should start it as below:
# Runs two workers in separate processes.
$ RAILS_ENV=production script/delayed_job -n 2 start
I am not familiar with delayed_job on Heroku, please follow its instructions.
This is very simple I guess, but still..
I have a background task with Resque that is failing and the output is too long to see in Terminal window.. I think it's time to log it. I execute it through
bundle exec env rake resque:work QUEUE='*'
Question is - how do I save that output to log file?
I looked at logging (development.log and it's not showing there of course, b/c it's happening on rake side)...
Thanks!
Take a look at this pull request:
https://github.com/sj26/resque/commit/05e4c5e6f92fe62b25db40984b20dad4b9f870d8
And read the readme. Have you tried to set VVERBOSE=1?
You could just send the output to a file:
bundle exec env rake resque:work QUEUE='*' >> log/resque.log
I run resque like that on my server
nohup bundle exec rake resque:work QUEUE=general PIDFILE=tmp/pids/resque_worker_QUEUE.pid & >> log/resque_worker_QUEUE.log 2>&1
Can't tell you it's the best way, but it works.