The following is a way to determine where in the codebase
bundler is stalling when fetching from external sources (rubygems.org, github.com, etc.). Use this as a way to determine where in the codebase
bundler is stalling when it is happening without stopping the process or requiring modifications to the source directly.
- Download the
bundler_trap.rbscript and put is somewhere easily accessible (I use the home directory in my examples).
- Run bundler using the following command:
ruby -I~ -rbundler_trap bin/bundle update
- You will have to repeat step to until you get to a situation where
bundlerhas stalled. When it does, send the
INFOsignal to the process (
CMD+ton OSX, and on Linux, it should be
kill -sINFO pid, but you might have to use a different signal).
This should print out debugging information regarding the current state of all of the threads used by bundler so we can determine where a fix needs to be made. This won't kill the process so this can be run mutiple times, and should be obvious on the start and end of the output.
I personally have found issues with running parallel requests when fetching the index from rubygems, so this is optimized to highlight issues from there and determine if it is a specific request or just common issue (in my case, it was an issue with the
Net::HTTP#connect method not timing out when failing to connect to a host. This could be from my ISP, crappy WiFi setup, or otherthings unrelated to the codebase). I have also attempted to highlight any threads currently working on shell out commands, which should include any
git based requests.
The idea for the script comes from the following excellent blog posts: