I was trying to run
heroku run rake db:migrate
And was getting the error
Cannot run more than 1 Free size dynos.
See below for how to fix...
Most Efective
in console run:
heroku ps
the result is some like this:
run.4859 (Free): up 2016/01/12 21:28:41 (~ 7m ago): rails c
So the numbers 4859 represent the session that is open and needs to be closed. To fix the error you need to run(Obviusly, replace the number 4859 by the number obtained):
heroku ps:stop run.4859
It is a very simple solution.
The answer is to look for any open heroku sessions (you can use 'heroku ps' as john points out above), in my case I already had a started a heroku console session 30mins earlier and just forgot about it. So if you see the "Cannot run more than 1 Free size dynos" error just close any existing console or other heroku sessions you have open.
Hopefully this saves someone the ten minutes it took me to come to my senses.
Had the exact same issue and came to this page. After reading realized what was going on but want to add following.
just run
heroku kill DYNO --app your_app_name
After this close all open consoles.
Then run db migrate command, it will work.
In my case, I ran heroku ps:restart to restart all dynos and the heroku run * command worked again.
Examples
If you just have one Git remote for Heroku, use this:
heroku ps:restart && heroku run *
If you have multiple Git remotes for Heroku, use this:
heroku ps:restart --remote your-remote-name && heroku run * --remote your-remote-name
OR
heroku ps:restart --app your-heroku-app-name && heroku run * --app your-heroku-app-name
Replace * with your command e.g. console for Rails console.
What I meant by your-heroku-app-name here is the sub-domain for your Heroku app. For example, if your app URL is https://cute-cat.herokuapp.com, that means your-heroku-app-name is cute-cat.
If you are not sure/forgot what's your Git remote name for Heroku, git remote -v can help you with that.
Example:
$ git remote -v
this-is-the-remote-name https://git.heroku.com/xxx.git (fetch)
this-is-the-remote-name https://git.heroku.com/xxx.git (push)
this-is-another-remote-name https://git.heroku.com/yyy.git (fetch)
this-is-another-remote-name https://git.heroku.com/yyy.git (push)
Just restart all dynos.
heroku restart
For me there was one command running on the web run console, I just ended its session there and it was resolved.
Heads up: Heroku free tier is going away soon
"What happens if I take no action on my free apps or databases or do not upgrade to a paid plan?
free dynos will be scaled down to 0 and hobby-dev databases will be deleted starting November 28, 2022."
"Starting November 28, 2022, free Heroku Dynos, free Heroku Postgres, and free Heroku Data for Redis® plans will no longer be available. If you have apps using any of these resources, you must upgrade to paid plans by this date to ensure your apps continue to run and retain your data. See our blog and FAQ for more info."
REF:
https://blog.heroku.com/next-chapter
https://devcenter.heroku.com/articles/free-dyno-hours
https://help.heroku.com/RSBRUH58/removal-of-heroku-free-product-plans-faq
Related
I have successfully deployed by rails app to Heroku, no problems. But now I am unable to update it with changes that I make to my code. When I try:
git add .
git commit -m "asdasd"
git push heroku master
I am told:
On branch master
Your branch is up-to-date with 'heroku/master'.
nothing to commit, working tree clean
I have tried Heroku ps, which gives me this:
Free dyno hours quota remaining this month: 541h 43m (98%)
Free dyno usage for this app: 0h 0m (0%)
For more information on dyno sleeping and how to upgrade, see:
https://devcenter.heroku.com/articles/dyno-sleeping
=== web (Free): bin/rails server -p $PORT -e $RAILS_ENV (1)
web.1: up 2019/01/18 14:37:10 -0600 (~ 2m ago)
So it seems like nothing is really going on, and for some reason there is no way of reaching the heroku site through the cli. The logs don't show anything interesting, just simply fetching pages and the like.
The only other thing is that I changed the name of the site in the heroku website, and I think there was something I should have done in the cli, but now I've lost it. In the cli the name of the app is the same so I guess this isn't a problem.
Can anyone help? Much thanks :-)
You can search on the web interface settings your project's git repository url and check if is the same that your local remote has.
.git/config
[remote "heroku"]
url = https://dir/repo.git
fetch = +refs/heads/*:refs/remotes/heroku/*
I am trying to deploy a basic app from Github to Heroku.
Following directions from Heroku's guide
Here's the thing. When I clone from the github repository, I clone a specific branch that's 8 commits ahead of master.
The reason why I clone that specific branch is that it's the most advanced on. Each branch is built upon the previous branch.
I don't want to merge that branch into the master because I don't know how to undo that.
By the time I try to do this step from the guide above: heroku ps:scale web=1, I always get this: Scaling dynos... failed
! App must be deployed before dynos can be scaled.
Why does this happen? Advice?
Please let me know if this question needs further clarification. Thank you.
EDIT
For the record, it has the Procfile which has this in it: web: bundle exec unicorn -p $PORT -c ./config/unicorn.rb
EDIT 2
When I do git push heroku branch_name - this is what I get:
Delta compression using up to 4 threads.
Compressing objects: 100% (243/243), done.
Writing objects: 100% (389/389), 727.55 KiB | 0 bytes/s, done.
Total 389 (delta 111), reused 389 (delta 111)
remote: Pushed to non-master branch, skipping build.
EDIT 3
I followed the first answer from this thread.
It worked, and restarted the app in Heroku.
But I restarted it again with this line: heroku restart --app name_of_app_in_heroku and got this: Restarting dynos... done
Then I tried to do heroku open --app name_of_app_in_heroku, and all I get is the basic welcome page. How do I overcome this?
Also, I just looked at my Heroku's dashboard, and checked the app, and it says it has no dynos. How is that possible?
EDIT 4
Also, I just ran this command: heroku pg:info and got this answer: name_of_app_in_heroku has no heroku-postgresql databases.
But that shouldn't be, I can see the DB's URL in the app's config vars in the settings of the app's dashboard.
It sounds like the app's never been deployed (because you're trying to deploy non master branch and heroku has been ignoring the pushes)
When you push to heroku, the name for the branch needs to be master on the heroku side.
By default git push keeps the same name for both sides:
git push heroku some_branch
Tries to (assuming upstream is setup appropriately etc) update a branch called "some_branch" on the heroku remote, with your local branch of the same name.
To use a different name you'd do
git push heroku some_branch:master
Which means push the changes from the branch called some_branch locally to heroku's master branch
When you deploy your app try doing this
gp heroku master -f
heroku run rake db:migrate --app APPNAME
heroku restart --app APPNAME
heroku open --app APPNAME
This are the lines that I use when I deploy a project to Heroku
This terminal command restarts my heroku application:
heroku restart
Is there a way to run a script that will run this command and restart my application every hour?
I actually just had to solve this problem for my apps and wrote a post on it with more details. Basically, you need the heroku-api gem now since the heroku gem is replaced by the CLI. Then you need a rake task, a couple of config variables and the heroku scheduler plugin (free except for minimal dyno time).
The rake task looks like this:
namespace :heroku do
desc 'restarts all the heroku dynos so we can control when they restart'
task :restart do
Heroku::API.
new(username: ENV['HEROKU_USERNAME'], password: ENV['HEROKU_PASSWORD']).
post_ps_restart(ENV['HEROKU_APP_NAME'])
end
end
You can also set it up to use your API token instead of putting your username and password into the config. This only matters if you don't want your co-contributors/coworkers knowing your password or the password to your main account on Heroku.
heroku config:set HEROKU_USERNAME=[username] HEROKU_PASSWORD=[password] HEROKU_APP_NAME=[app_name] -a [app_name]
Now, go ahead and deploy and test:
git push [heroku_remote_name] [feature_branch]:master
heroku run rake heroku:restart -a [app_name]
Lastly, we’ll need to set up the task to run this on schedule. I’ve chosen to go with the free Heroku cron add-on:
heroku addons:add scheduler:standard -a [app_name]
heroku addons:open scheduler -a [app_name]
This will open up the scheduler UI in your browser and you can create a scheduled worker to run the rake task whenever you’d like. We only need it once per day and we’re choosing to run it before our first scheduled job of the day.
My original post with frigged up CSS (see update2 below):
https://web.archive.org/web/20150612091315/http://engineering.korrelate.com/2013/08/21/restart-heroku-dynos-on-your-terms/
UPDATE
I changed the name of the task from "implode" to "restart" to be way more clear as to what is happening. Implode is a fun name but pretty much useless otherwise.
UPDATE2
Apparently my company removed the blog post. I'm adding more of the code here and I've updated the link, but the CSS looks like a dog threw it up. My apologies.
You could create a heroku cron job that uses the Heroku api on your application to restart itself...
One question though - why?
We solved this by using a buildpack to get the heroku command available to the dyno itself, then using Heroku Scheduler.
We added the https://github.com/gregburek/heroku-buildpack-toolbelt buildpack per its instructions:
heroku buildpacks:add https://github.com/gregburek/heroku-buildpack-toolbelt.git
heroku config:add HEROKU_TOOLBELT_API_EMAIL=`heroku whoami`
heroku config:add HEROKU_TOOLBELT_API_PASSWORD=`heroku auth:token`
Then made sure the app slug was rebuilt per the instructions:
git push heroku master
In Heroku Scheduler, we added this as a hourly job:
vendor/heroku-toolbelt/bin/heroku ps:restart -a $HEROKU_APP_NAME
You can determine if it's working by looking for Scheduler output in the Heroku logs, and of course by the memory graph of the app in the Heroku dashboard (if you're restarting to work around a memory leak).
A script isn't necessary, just "crash" your application and Heroku will restart it.
Just don't do this more frequently than once every ten minutes or Heroku will subject you to a 10 minute timeout.
In node.js you do this with process.exit(0).
From Chris at Heroku Support:
A crashed dyno will be restarted immediately. If the dyno moves from a
crashed state into an "up" state (meaning that the dyno bound to
$PORT) then it's subject to being a normal running dyno. If it crashes
again during the boot or "starting" sequence then it won't be
restarted again until after the TIMEOUT period. The TIMEOUT period is
currently 10 minutes but that is subject to change. This prevents
dynos that are continually crashing from putting extraneous load on
the platform.
However, as good as that sounds, it doesn't work in practice. You will hit the timeout every time you exit because the dyno manager expects your app to be up:
For your worker process management you're exiting the process cleanly
but the platform is expecting the dyno to be up. It sounds like you're
essentially crashing the dyno as a result.
So again, if you need to restart periodically -- and that period can be set to > 10 minutes -- this is a easy and simple way to manage memory clearing. If you need to reboot dynamically (for example, when idle is detected) or frequently you will need to explore other options.
You can access the name of the dyno (ex. "worker.3", "web.1") through the environment variable "PS" and issue a heroku API restart command programmatically.
Inspired by https://www.stormconsultancy.co.uk/blog/development/ruby-on-rails/automatically-restart-struggling-heroku-dynos-using-logentries/
# Setup
heroku plugins:install https://github.com/heroku/heroku-oauth
heroku authorizations:create -s write
heroku config:add RESTART_API_KEY=<API KEY>
heroku config:add APP_NAME=<App Name>
heroku addons:add scheduler:standard -a <App Name>
heroku addons:open scheduler -a <App Name>
add `rake restart`
# Gemfile
gem 'platform-api', require: false
# Rakefile
task :restart do
require 'platform-api'
app_name = ENV.fetch('APP_NAME')
key = ENV.fetch('RESTART_API_KEY')
connection = PlatformAPI.connect_oauth(key)
connection.dyno.list(app_name).map do |info|
if info['type'] == 'web' && info['state'] == 'up'
puts "Restarting #{info.inspect}"
connection.dyno.restart(app_name, info['name'])
else
puts "Skipping #{info.inspect}"
end
end
end
I solved this with a very simple curl command script within the repo that is triggered using the free Heroku scheduler.
#!/bin/sh
curl -X DELETE "https://api.heroku.com/apps/${HEROKU_APP_NAME}/dynos" \
--user "${HEROKU_CLI_USER}:${HEROKU_CLI_TOKEN}" \
-H "Content-Type: application/json" \
-H "Accept: application/vnd.heroku+json; version=3"
See https://gist.github.com/mattheworiordan/f052b7693aacd025f025537418fa5708.
We've given our app a long-running token to use to authenticate with the Heroku API, and simply included a curl request in our code to restart the app.
Create a long-running API token:
$ heroku authorizations:create --description="Long-lived token for app restarts"
Creating OAuth Authorization... done
Client: <none>
ID: abcdabcd-abcd-4bcd-abcd-abcdabcdabcd
Description: Long-lived token for app restarts
Scope: global
Token: 12341234-1234-4234-1234-123412341234
Updated at: Tue May 11 2021 09:16:38 GMT-0400 (Eastern Daylight Time) (less than a minute ago)
Note the Token. We've stored it in the ENV via heroku config, along with the app name:
$ heroku config:set HEROKU_API_TOKEN=12341234-1234-4234-1234-123412341234 HEROKU_APP_NAME=not-really-an-app
In our code we have the following method to restart the app via Heroku's API, using this API call:
def restart!
# Using puts to log output, replace with your logging system if needed
puts `curl -v -s -n -X DELETE https://api.heroku.com/apps/#{ENV["HEROKU_APP_NAME"]}/dynos -H "Content-Type: application/json" -H "Accept: application/vnd.heroku+json; version=3" -H "Authorization: Bearer #{ENV["HEROKU_API_TOKEN"]}"`
end
Finally, as you're interested in automatic restarts every hour, the restart! method above can be scheduled using Heroku's Scheduler, rufus-scheduler, as a Sidekiq job, or otherwise.
Note: Heroku has some limits/timing logic around app restarts, mostly centered around dyno crashes. Reading the docs may help inform your app restart strategy.
As far as I can tell, simply running heroku ps:restart --app APPNAME in the Heroku Scheduler add-on works fine. It's unclear to me why the additional steps in other answers are necessary.
I am working my way through Michael Hartl's Ruby on Rails Tutorial (on Mac OSX 10.7.2/Ruby 1.9.2/Rails 3.1.1) and just finished Chapter 2, which concludes with deploying a demo twitter app to Heroku.
Everything appears to be working properly when I run the app locally AND I was able to successfully deploy the app to Heroku in some capacity because it is available here: http://rich-twitter-baby.heroku.com/
However, what I can't figure out is why the /users and /microposts pages aren't showing up publicly (with lists of users and microposts respectively) as they do locally. I migrated my database to Heroku and pushed the info up there and everything seemed to work properly, but I get this error message when I try to view the pages publicly.
I've tried running "heroku console" but get this error:
Unable to attach to a dyno to open a console session.
Your application may have crashed.
Check the output of "heroku ps" and "heroku logs" for more information.
And the logs say error H13, while the ps looks like this:
Process State Command
------------ ------------------ ------------------------------
web.1 idle for 1h thin -p $PORT -e $RACK_ENV -R $HER..
Let me know if anyone has any ideas or if more info would help.
Thanks!
I would contact Heroku support on this. Dynos can crash and become 'zombiefied' which means they just sit there idle.
Normally these will clear themselves out within a few hours, but it shouldn't happen that often if at all.
Doing a new deploy will also normally restart everything back to clean.
If it's consistently happening, have you tried spinning up the application locally in production mode to try and reproduce the problem
rails server -e production
, or adding something like the Airbrake add-on to your app to capture the error.
Check your log using
$> heroku logs
At the command line of your development system that you used to push to heroku.
Post the log here if you can't figure it out from that.
I contacted Heroku Support about this issue and it turns out that the answer had to do with which stack my app was being deployed to. I did their workaround and everything is now up and running. Here's the full info from them:
It looks like the problem is that you're using Rails 3.1 and our Bamboo stack; we have full >asset pipeline support on our Cedar stack[1]. Since this is just a demo app, an easy >workaround is to precompile locally and commit the files:
rake assets:precompile
git add -A
git commit -m "precompiling assets"
git push heroku master
To get full asset pipeline support, you need to create your app on the Cedar stack and then >repeat the process you did to get your Bamboo app to work.
[1]: http://devcenter.heroku.com/articles/rails31_heroku_cedar
Is there a faster way to transfer my production database to a test app?
Currently I'm doing a heroku db:pull to my local machine then heroku db:push --app testapp but this is becoming time consuming. I have some seed data but it is not nearly as accurate as simply testing with my real-world data. And since they're both stored on a neighboring AWS cloud, there must be a faster way to move the data?
I thought about using a heroku bundle, but I noticed the animate command is gone?
bundles:animate <bundle> # animate a bundle into a new app
It's quite common to migrate databases between staging, testing and production environments for Rails Apps. And heroku db:pull/push is painfully slow. The best way I have found so far is using Heroku PG Backups add-on and it's free. I followed following steps to migrate
production database to staging server:
1) Create the backup for the production-app db
heroku pg:backups capture --app production-app
This will generate b001 backup file from the main database (usually production db in database.yml)
2) To view all the backups (OPTIONAL)
heroku pg:backups --app production-app
3) Now use the pg:backups restore command to populate staging server database from the last backup file on production server
heroku pg:backups restore $(heroku pg:backups public-url --app production-app) DATABASE_URL --app staging-app
Remember that restore is a destructive operation, it will delete existing data before replacing it with the contents of the backup file.
So things are even easier now .. checkout the transfer command as part of pgbackups
heroku pgbackups:transfer HEROKU_POSTGRESQL_PINK sushi-staging::HEROKU_POSTGRESQL_OLIVE -a sushi
https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases#4b-alternative-transfer-data-between-applications
This has worked beautifully for me taking production code back to my staging site.
The correct answer has changed again as of March 11, 2015.
heroku pg:backups restore $(heroku pg:backups public-url --app myapp-production) DATABASE_URL --app myapp-staging
Note specifically that the argument is now public-url.
https://blog.heroku.com/archives/2015/3/11/pgbackups-levels-up
Update for mid-2015...
The pgbackups add-on has been deprecated. No more pgbackups:transfer. pg:copy is ideal for this scenario.
To copy a database from yourapp (example db name: HEROKU_POSTGRESQL_PINK_URL to yourapp_staging (example db name: HEROKU_POSTGRESQL_WHITE_URL)
# turn off the web dynos in staging
heroku maintenance:on -a yourapp-staging
# if you have non-web-dynos, do them too
heroku ps:scale worker=0 -a yourapp-staging
# backup the staging database if you are paranoid like me (optional)
heroku pg:backups capture -a yourapp-staging
# execute the copy to splat over the top of the staging database
heroku pg:copy yourapp::HEROKU_POSTGRESQL_PINK_URL HEROKU_POSTGRESQL_WHITE_URL -a yourapp-staging
Then when it's complete, turn staging back on:
# this is if you have workers, change '1' to whatever
heroku ps:scale worker=1 -a yourapp-staging
heroku maintenance:off -a yourapp-staging
Reminder: you can use heroku pg:info -a yourapp-staging (and yourapp) to get the database constants.
(source: https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases#upgrade-with-pg-copy-default)
psql -h test_host -c 'drop database test_db_name; create database test_db_name;'
pg_dump -h production_host production_db_name | psql -h test_host test_db_name`
This can be done on production_host or on test_host — will work both ways.
Have not tested this, but it might work.
Do this to get the URL of your source database:
heroku console "ENV['DATABASE_URL']" --app mysourceapp
Then try executing db:push with that.
heroku db:push database_url_from_before --app mytargetapp
This might not work if Heroku doesn't allow access to the DB machines from outside their network, which is probably the case. You could, perhaps, try using taps (gem that heroku db commands use internally) from within your app code somewhere (maybe a rake task). This would be even faster than the above approach because everything stays completely within AWS.
Edit:
Here's an (admittedly hacky) way to do what I described above:
Grab the database URL as in the first code snippet above. Then from a rake task (you could do it on console but you risk running into the 30 second timeout limit on console commands), execute a shell command to taps (couldn't easily determine whether it's possible to use taps directly from Ruby; all docs show use of the CLI):
`taps pull database_url_from_source_app #{ENV['DATABASE_URL']}`
The backticks are important; this is how Ruby denotes a shell command, which taps is. Hopefully the taps command is accessible from the app. This avoids the problem of accessing the database machine from outside Heroku, since you're running this command from within your app.
Heroku enables you to fork existing applications in production. Use heroku fork to copy an existing application, including add-ons, config vars, and Heroku Postgres data.
Follow the instructions on Heroku: https://devcenter.heroku.com/articles/fork-app
Update for mid-2016...
Heroku now have a --fast flag when creating forks, however they will be up to 30 hours out-of-date.
$ heroku addons:create heroku-postgresql:standard-4 --fork HEROKU_POSTGRESQL_CHARCOAL --fast --app sushi
https://devcenter.heroku.com/articles/heroku-postgres-fork#fork-fast-option