CODEWITHSUNDEEP
rubyrubygemsbundler
RazokKull
RazokKull

Reputation: 487

Bundler, when attempting to update or install, will hang forever

When attempting to run bundle install or bundle update, bundler will perpetually hang, and not complete its function. The only time that it will finish is when I specify a gem to update.

For example:

bundle update

Will hang forever unless I use it like this:

bundle update activerecord

Then it will complete as normal.

Any assistance would be appreciated.

Upvotes: 29

Views: 25014

Answers (5)

rgkobashi
rgkobashi

Reputation: 2698

For me what worked was deleting the Gemfile.lock, it will be generated anyways

Upvotes: 0

New Alexandria
New Alexandria

Reputation: 7324

This problem is due to a missing dependency, or worse a dependency-of-a-dependency. It's common when you don't use rubygems.org as your gemserver (an enterprise environment).

Common patterns:

  • You don't have that gem installed
  • You don't have the dependencies of that gem installed
  • You don't have that gem installed without its dependencies
  • User account that runs a script does not have permissions to install that gem

Easiest Technique

create a new gemset, and re-bundle. This fixes the problem many times.

If you can't do that for production reasons, and you don't have an app history from which to reflect on when the problem gem was added, then:

Easier Technique

Having learned a bit since writing this answer, I thought I'd pass on this excellent article for how to run bundler with verbose debug output

export DEBUG_RESOLVER=1
bundle  2> debug_output.txt 1> stdio.txt &

This will dump all the debugging (err) output to debug_output.txt and the normal screen stuff to stdio.txt.

You'll want to dump 1> as well because every time bundler dumps a line to 2(stderr) it will put a crlf into 1. So Either dump 1 or background the job. I do both so I can work in the same terminal.

I usually follow it up with:

tail stdio.txt

to be sure things have started, then:

tail -n 10000 -f debug_output.txt

To search with /FAIL] through the file for failed attempts to install a dependency. Find a couple of them that are the same and you've generally located your culprit. The stderr works for bundle install or bundle update.

Debug Your Private Gemserver Technique

I needed to use this process-of-elimination method to determine that my (enterprise) gemserver index had become corrupted

  1. comment out all gems
  2. run bundle update to confirm the empty-set works
  3. un-comment one gem and bundle update
  4. GOTO 3 until you hit the problem
  5. research its dependencies

When you are done

Unset the ENV var with

unset DEBUG_RESOLVER

Solution for permissions

Ensure that the credentials in your GITHUB_TOKEN matches your bundle config --global github.com <your token>

Upvotes: 34

Billy
Billy

Reputation: 563

When deploying onto AWS instances, be sure your security group allows outbound HTTP and/or HTTPS connections - I encountered this problem because I had restricted the security group too much.

Upvotes: 1

justingordon
justingordon

Reputation: 12903

Bundler may not be hanging. I just experienced a 7 minute time to bundle a relatively small Gemfile, and that is on the fastest possible SSD Macbook Pro with a 50 Gb download connection.

Upvotes: 3

Travis Reeder
Travis Reeder

Reputation: 41103

You can try the --verbose flag too to get more output, but it's really archaic and not very helpful. Really the only way to do this from what I can see is:

  1. Uncomment one gem at a time until it stops working, then try to figure out what the heck is going.
  2. Remove version enforcement one gem at a time (if any) to see if that fixes it.
  3. Remove the offending gem if you can (use a different gem) or lock in versions that do work.

For me, after running:

sudo bundle update --verbose

it kept hanging here:

Query Gemcutter Dependency Endpoint API: tenderlove-frex
Fetching from: http://rubygems.org/api/v1/dependencies?gems=tenderlove-frex
HTTP Success
Query List: []

Not at all helpful. I ended up figuring out that the conflict was between two gems. The following would hang forever:

source 'http://rubygems.org'
gem 'rails', '~> 3'
gem 'airbrake'

I removed the rails version:

source 'http://rubygems.org'
gem 'rails'
gem 'airbrake'

Then it worked, but I noticed in my Gemfile.lock that it was using Rails 2.3.X. So airbrake seemed to be dependent on Rails 2, but I wanted 3. I couldn't find anywhere that airbrake had this Rails 2.x dependency so not sure why it ended up like that. Why bundler can't output something more meaningful is beyond me.

This worked though:

source 'http://rubygems.org'
gem 'rails', '~> 3'
gem 'airbrake', '~> 3'

I really think there is something wrong with Bundler, but not sure.

Upvotes: 9

Related Questions