Rails 3 / Heroku infinite zombie dynos with simple app deploy - too busy to open console

The fact that there are so few results Googling around on this makes me think I am doing something totally wrong, because it seems like this would be an incredibly common problem. However I can't seem to find an easy solution and Heroku's docs suck in general, and their support takes >1 day to respond, so here I am.

I have an app that I am trying to deploy for the first time. It is a very lite app, almost a shell app. It works on dev and then crashes when I deploy to heroku with an unhelpful HTML error page:

    Application Error
    An error occurred in the application and your page could not be served. 
Please try again in a few moments.    
    If you are the app开发者_StackOverflow社区lication owner, check your logs for details.

Ok, better check the logs. But Heroku logs tells me nothing:

Ovid:volatilityApp dlipa$ heroku logs
Ovid:volatilityApp dlipa$ 

Ovid:volatilityApp dlipa$ heroku logs -n 300
Ovid:volatilityApp dlipa$ 

OK, hmm..better log into the console to see what is going on.

Ovid:volatilityApp dlipa$ heroku console
Your application is too busy to open a console session.
Console sessions require an open dyno to use for execution.

Hmm that sucks, lets look at what is running.

Ovid:volatilityApp dlipa$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         crashed for 4m      thin -p $PORT -e $RACK_ENV -R $HER..

Makes sense..but why doesn't Heroku's dyno grid clear this out? No info on topic on Heroku site. Googling around leads to http://neilmiddleton.com/avoiding-zombie-dynos-with-heroku

Ok cool so I install the rack-timeout gem and add the initializer and push to heroku. I watch it complete the 'bundle install'. But still the same problem...

Ovid:volatilityApp dlipa$ heroku console
Your application is too busy to open a console session.
Console sessions require an open dyno to use for execution.

Argh this is really cryptic and starting to become frustrating. Maybe I should just buy some more resources from Heroku...that should solve the problem, because then I will have more dynos to open the console..

Ovid:volatilityApp dlipa$ heroku dynos
volatility is running 1 dyno

Ovid:volatilityApp dlipa$ heroku dynos 2
volatility now running 2 dynos

But wait, Heroku loads as many web processes as I have dynos, and they all zombie out! And I can't get into the console no matter how high I scale.

Ovid:volatilityApp dlipa$ heroku dynos 10
volatility now running 10 dynos
Ovid:volatilityApp dlipa$ heroku ps
heroku consoleProcess       State               Command
------------  ------------------  ------------------------------
web.1         crashed for 2m      thin -p $PORT -e $RACK_ENV -R $HER..
web.2         crashed for 1m      thin -p $PORT -e $RACK_ENV -R $HER..
web.3         crashed for 37s     thin -p $PORT -e $RACK_ENV -R $HER..
web.4         crashed for 36s     thin -p $PORT -e $RACK_ENV -R $HER..
web.5         crashed for 35s     thin -p $PORT -e $RACK_ENV -R $HER..
web.6         crashed for 35s     thin -p $PORT -e $RACK_ENV -R $HER..
web.7         crashed for 37s     thin -p $PORT -e $RACK_ENV -R $HER..
web.8         crashed for 33s     thin -p $PORT -e $RACK_ENV -R $HER..
web.9         crashed for 38s     thin -p $PORT -e $RACK_ENV -R $HER..
web.10        crashed for 34s     thin -p $PORT -e $RACK_ENV -R $HER..
Ovid:volatilityApp dlipa$ heroku console
Your application is too busy to open a console session.
Console sessions require an open dyno to use for execution.
Ovid:volatilityApp dlipa$ 

Is it me or is this poorly designed? Why is there no information on this subject? Am I doing something totally wrong?

Thanks for your help!

App running 3.0.5 rails, 1.9.2 ruby, postgresql.

--UPDATE IN RESPONSE TO BANTIC--

Ovid:volatilityApp dlipa$ heroku stack
  aspen-mri-1.8.6
  bamboo-ree-1.8.7
* bamboo-mri-1.9.2

Ovid:volatilityApp dlipa$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         crashed for 17s     thin -p $PORT -e $RACK_ENV -R $HER..
web.2         crashed for 1m      thin -p $PORT -e $RACK_ENV -R $HER..
web.3         crashed for 1m      thin -p $PORT -e $RACK_ENV -R $HER..

RubyGems Environment:
  - RUBYGEMS VERSION: 1.6.1
  - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-darwin10.6.0]
  - INSTALLATION DIRECTORY: /Users/dlipa/.rvm/gems/ruby-1.9.2-p180
  - RUBY EXECUTABLE: /Users/dlipa/.rvm/rubies/ruby-1.9.2-p180/bin/ruby
  - EXECUTABLE DIRECTORY: /Users/dlipa/.rvm/gems/ruby-1.9.2-p180/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-darwin-10
  - GEM PATHS:
     - /Users/dlipa/.rvm/gems/ruby-1.9.2-p180
     - /Users/dlipa/.rvm/gems/ruby-1.9.2-p180@global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://rubygems.org/", "http://gems.github.com"]
  - REMOTE SOURCES:
     - http://rubygems.org/
     - http://gems.github.com

Link to repo:

https://github.com/lightserve/volatilityApp

Are you running the same stack on heroku as locally? Heroku new apps defaulto mri ruby 187, afaik. You might try migrating your heroku stack to 1.9.2. You can do that via:

heroku stack:migrate bamboo-mri-1.9.2

Next time you push to your heroku git repo, the stack will get migrated.

Can you give more information about what your app does? Is it spawning new processes or using threads?

I came to this thread because I had the same problem. In my case, the problem was an error in the "routes.rb" file.