brew doctor and brew upgrade stopped working #18045

Closed
deiga opened this Issue Feb 23, 2013 · 27 comments

Projects

None yet

10 participants

@deiga
Contributor
deiga commented Feb 23, 2013

Today I updated for the 2nd or 3rd time my brew and ran upgrade.
Upgrading gtk+ brought everything to a standstill and it didn't do anything for hours. Then I tried running doctor but it too doesn't do anything for hours. Installing and removing still works...

I'm not really sure what's going on here. Any hints?

@deiga
Contributor
deiga commented Feb 25, 2013

Okay, I uninstalled gtk+ and octave. Still doctor or install octave don't work (verbose shows nothing for hours).
Brew does update's and installs of other software fine.
Whats going on here? What can I do to fix this?

@adamv
Contributor
adamv commented Feb 25, 2013

Does brew --config work?

@MikeMcQuaid
Member

Sounds like the issue @samueljohn described.

@samueljohn
Contributor

Do xcrun and ruby call each other in a loop? (You can see this in the terminal title or in the activity monitor)

@deiga
Contributor
deiga commented Feb 25, 2013

@adamv Only half way.

 ~/dotfiles/ [master*] brew --config
HOMEBREW_VERSION: 0.9.4
ORIGIN: https://github.com/mxcl/homebrew.git
HEAD: 0baac3bf5faa391d0748dccf6b424bfac05c6801
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: dual-core 64-bit penryn
OS X: 10.8.2-x86_64
Xcode: 4.6
CLT: 4.6.0.0.1.1358221012
LLVM-GCC: build 2336
Clang: 4.2 build 425

It has been stuck there for hours (running brew(mdfind)) currently

@deiga
Contributor
deiga commented Feb 25, 2013

@samueljohn I've been watching it for a while now, but it only seems to run ruby. At least I haven't noticed it switching

@deiga
Contributor
deiga commented Feb 25, 2013

I went and tried the PR of @samueljohn but it doesn't seem to fix my problem...

@samueljohn
Contributor

Ok then this is unrelated to the xcrun bug. Does your mdfind hang on
the terminal, too?

@deiga
Contributor
deiga commented Feb 26, 2013

@samueljohn yes it does, after a while. So this means my spotlight is borked? How the hell do I debug that?

@lancelakey

My brew upgrade and brew doctor also no longer "work" i.e. they don't finish running or return anything. I eventually have to Ctrl-C out of them.

When I run either brew upgrade, brew doctor, or brew --config I see in top that xcrun uses around 95% CPU until I Ctrl-C out of the brew command.

~ > brew --config
HOMEBREW_VERSION: 0.9.4
ORIGIN: https://github.com/mxcl/homebrew
HEAD: c64a2a8fe19c300dd99af8cca665bd17fad64c90
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: quad-core 64-bit ivybridge
OS X: 10.8.3-x86_64
@MikeMcQuaid
Member

@lancelakey Is Spotlight working?

@lancelakey

@mikemcquaid Spotlight seems to work fine. I just found a plain text file using Spotlight.

@samueljohn
Contributor

What does xcode-select --print-path show?

@deiga
Contributor
deiga commented Apr 5, 2013

Although I currently don't have this problem anymore:
/Applications/Xcode.app/Contents/Developer

@lancelakey

@samueljohn

~ > xcode-select --print-path
/

I recently updated the xcode clitools using: xcode461_cltools_10_86938245a.dmg

@mistydemeo
Contributor

@lancelakey Setting the xcode-select path to / exposes an endless loop bug in the xcrun tool that's a part of Xcode/CLT.

If you have Xcode installed, change it to the location of Xcode.app. Otherwise, unset it by deleting the files in /usr/share/xcode-select/.

@lancelakey

@mistydemeo Awesome. Thanks!

removing /usr/share/xcode-select/ resolved my issue.

~ > xcode-select 
xcode-select: Error: no command option given.

xcode-select: Report or change the path to the active
              Xcode installation for this machine.

Usage: xcode-select --print-path
           Prints the path of the active Xcode folder
   or: xcode-select --switch <xcode_path>
           Sets the path for the active Xcode folder
   or: xcode-select --version
           Prints the version of xcode-select

~ > brew --config
HOMEBREW_VERSION: 0.9.4
ORIGIN: https://github.com/mxcl/homebrew
HEAD: c64a2a8fe19c300dd99af8cca665bd17fad64c90
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: quad-core 64-bit ivybridge
OS X: 10.8.3-x86_64
CLT: 4.6.0.0.1.1362189000
LLVM-GCC: build 2336
Clang: 4.2 build 425
X11: N/A
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/local/bin/python => /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /Users/lance/.rbenv/shims/ruby
~ > brew upgrade
==> Upgrading 9 outdated packages, with result:
@MikeMcQuaid
Member

@mistydemeo Perhaps we can/should detect that before calling them?

@mistydemeo
Contributor

@mikemcquaid The effects of it seem to be severe enough maybe we should have brew itself error out (with instructions for fixing the issue) before doing anything if xcode-select is set to /. We can't guarantee that it'll make it all the way to the appropriate doctor check before hanging eternally.

@samueljohn
Contributor

I thought we had fixed this already a hundred times :-)

For Xcode-only, I think, we have measures to deal with this. But if
the CLTs are installed, I don't know if that special handling is used.

@MikeMcQuaid
Member

@mistydemeo Yep, I think have brew itself error out and also perhaps make it the first doctor check too.

@designgears

I have this same issue. If I pull up the activity monitor and kill mdfind a few times everything completes fine. If I run

/usr/bin/mdfind "kMDItemCFBundleIdentifier == 'org.macosforge.xquartz.X11'"

I get the proper return

/Applications/Utilities/XQuartz.app

but it hangs, never terminates. Again, if I kill mdfind manually, everything continues just fine.

@lah435
lah435 commented Apr 29, 2013

removing /usr/share/xcode-select fixed the issue for me as well.

@adamv
Contributor
adamv commented May 6, 2013

Closing since the original poster says he's not having an issue anymore. #17102 appears related, and should be used for further discussion.

@adamv adamv closed this May 6, 2013
@joakin
joakin commented Jul 24, 2013

Just to leave my experience. From one day to another messing with ruby and gems, this started happening to me.

I did not notice any mdfind or xcrun excessive use of CPU and brew was hanging on brew --config, brew doctor, brew outdated, etc. With all of them it was without any output, but with brew --config where it would output:

HOMEBREW_VERSION: 0.9.4
ORIGIN: http://github.com/mxcl/homebrew.git
HEAD: 288f001e924d5365b79c279e4478f372a04011ae
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: 8-core 64-bit sandybridge
OS X: 10.7.5-x86_64

And then hanged.

My xcode-select --print-path output was /usr/bin. After doing a sudo mv /usr/share/xcode-select /usr/share/xcode-select.backup everything works perfectly*(see edit at the end, not true).

I don't know why it works, but it does. I hope this does not break more stuff on the future...

EDIT:
Doing that broke other things, like for example npm and node being unable to find the command line tools for compiling with gyp. To fix it I did sudo xcode-select -switch /Library/Developer and now both brew and npm detect the command line tools properly. It is extra-weird, since that folder is empty and only has a Ackowledgments.rtf
Anyway, there is that.
EDIT 2:
With this change I couldnt compile things with gem, so I had to create a symbolic link on /Library/Developer/usr/bin pointing to /usr/bin that is where the command line tools binaries are

@samueljohn
Contributor

I don't think this is a good way to fix it. I would recommend to name it back to original and set the Xcode-select path to /Applications/Xcode.app check with xcrun -find clang or something if it is working. The /usr/bin is not a valid path for xcode-select, I think. It could have been the reason for the hanging in the first place. But I am not sure why it occurred at one point. Probably due to the caching in xcrun.

@cweekly
cweekly commented Nov 19, 2013

FWIW, removing /usr/share/xcode-select fixed the issue for me too. (OSX 10.8.5, brew 0.9.5)

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.