I killed an IRB prompt in a not-so-graceful manner (started with heroku run irb), and now I've got a zombie process which I can't seem to kill:
Process State Command
------------ ------------------ ------------------------------
run.3 up for 2h irb -r ./init.rb
web.1 up for 0s thin -p $PORT -e $RACK_ENV -R $HER..
I've tried:
heroku restart
heroku ps:scale run=0
heroku ps:restart run.3
Anyone know how I can force quit it?
I noticed a new ps:stop command added to the Heroku command line client a few days ago:
https://github.com/heroku/heroku/commit/a6d9eb7f314bf2c5f162a508e8d764286fb577bb
I'm not sure if that change made it into version 2.9.0 but it would be worth a try.
Update
This is now in the Heroku Toolbelt. Just run:
heroku ps:stop <process id from heroku ps>
Example:
heroku ps:stop run.8729
Thanks James!! I needed to update my Heroku client first, and it worked like a charm.
$ sudo gem install heroku
$ heroku ps #to view processes
$ heroku stop <process name here>
edit: they've fixed this issue
Heroku doesn't have a way to kill abandoned run.x processes.
But it will be killed automatically after 24 hours.
If anyone else is struggling with killing using something like:
heroku run ps:stop run.789
Killing by id worked for me:
heroku ps:kill 61ff0687-eaf4-4299-9c65-f0b22af7ec67
I got the id using the platform api list dynos - https://devcenter.heroku.com/articles/platform-api-reference#dyno-list
Worked for a detached one-off that was abandoned.
Related
I'm trying to install heroku-accounts using this command:
$ heroku plugins:install heroku-accounts
but instead I got this:
heroku-cli: Updating plugins... !
/Users/hit/Library/Caches/heroku/update.lock is locked with a reader active: 17964
I try rm the update.lock but it still get same result
I solve the problem by updating Heroku (I use homebrew install heroku)
heroku update
brew upgrade heroku
None of the above answers seem to work for me. The issue happened when I updated my heroku-cli via brew to version heroku-cli/6.13.8 (darwin-x64) node-v8.2.1 .
Although Error was very explicit that one more process is running, ps | grep showed no such process.
The only solution was to Restart System Once.
There is another copy of the heroku CLI running with the PID 17964
You can find it by doing something like this:
ps | grep 17964
Once you stop that process try your install again.
In my Dev box on Nitrous, I am able to run God -c scripts.god -D to restart the two .rb files if they die.
I just run that and the processes for the most part stay alive.
But I cannot do the same in heroku. It seems when I run the god command the .god file does not open and generates an error in heroku.
Question:
How can I run God to restart failed processes in heroku as I do on my development Nitrous environment?
Or is there a recommended alternative way to watch heroku processes and restart them automatically when they fail?
On Heroku you shouldn't need to use a process supervisor like god. If all you need is to ensure your process is restarted if it crashes, Heroku can manage that fine.
It should be as simple as adding two entries in your procfile as workers. https://devcenter.heroku.com/articles/background-jobs-queueing
worker: bundle exec sidekiq
clock: bundle exec clockwork lib/clock.rb
slack_listener: bundle exec ruby lib/slack_bot.rb
You could possibly have issues, if your processing are crashing quite often. Dyno Crash Restart Policy
Your processes should start automatically when you access your website.
However, Heroku does provide commands to manage your processes, check out https://devcenter.heroku.com/articles/dynos for the complete list. E.g., to restart all processes, use the toolbelt command:
heroku ps:restart --app yourappname
Here's what happened...
pgbackups:capture gave the following:
! must delete a backup before creating a new one
...so I tried deleting a past backup:
$ heroku pgbackups
ID Backup Time Size Database
---- ------------------- ----- ---------------
b003 2012/07/16 11:27.19 2.4MB SHARED_DATABASE
b004 2012/08/09 05:27.57 2.5MB SHARED_DATABASE
$ heroku pgbackups:destroy b003
! Internal server error.
! Run `heroku status` to check for known platform issues.
$ heroku status
=== Heroku Status
Development: No known issues at this time.
Production: No known issues at this time.
Any ideas?
Apparently, the error was a "rare occurrence" -- according to Heroku Support.
BTW, the following command succeeded:
$ heroku pgbackups:capture -a <app_name> --expire
Update your heroku gem - that solved the problem for me
gem install heroku
Seems like a simple question, but I haven't found the answer anywhere. Running heroku ps shows nothing. heroku restart executes successfully.
Have you tried scaling one of your process types? e.g. heroku ps:scale web=1
See https://devcenter.heroku.com/articles/scaling
I was doing a silly mistake. I was using
heroku run ps (since there were other commands that I was using as "run")
instead of
heroku ps. (ps is a heroku command and not a system command).
Removing run fixed the issue. Thanks.
I've been trying to get a heroku console session going on cedar and am having no joy.
The old way was:
heroku console
I understand the new way involves 2 steps:
heroku run bash
then
$ rails console
but at the heroku run bash stage i keep geting:
heroku run bash
Running `bash` attached to terminal... up, run.1
!
! Timeout awaiting process
so i checked there isn't a port blocking issue and
telnet rendezvous.heroku.com 5000
gives
Trying 50.19.103.36...
Connected to ec2-50-19-103-36.compute-1.amazonaws.com.
Escape character is '^]'.
which is as expected i think
what am i doing wrong and what do i need to do to get this console up and running?
Thanks!
PS I have tried - heroku run console - also, and that times out too.
In cedar every command that needs to be attached to terminal uses run.
ex:
heroku run console
heroku run rake db:migrate
When its not necessary to be attached don't use the run:
ex: heroku logs
The new way is heroku run console
Ok - it was obvious after a few hours of sleep. Simply had to update the heroku gem that had got corrupted somehow on my mac. If you have something like this problem, then do that first...