10

When opening my activity monitor, I have a zsh process taking all my CPU. Is it normal? I have iTerm and oh-my-zsh installed but I don't expect it as a normal behaviour.

Any idea?

3
  • Is this reproducible for every new zsh session? If so, start with no zshrc files and narrow the problem down. Or is it only one process which has gone mad?
    – mpy
    Aug 27, 2014 at 18:08
  • I restarted my system and the process was no here anymore. It appears again once I started iTerm but with very low CPU (0.25%). Aug 28, 2014 at 8:55
  • This is a duplicate of another question apple.stackexchange.com/questions/146919/…. May 14, 2015 at 18:22

2 Answers 2

14

I encounter this problem a lot, too. It always involves installd, and most importantly, with installd installing/updating Apple apps, like iWork (IIRC it's iWork exclusive; at least I've yet to encounter an occurrence with a third party app).

I believe it has nothing to do with iTerm2 or oh-my-zsh (although I use both, too). What I believe is that this is a shell compatibility issue — Apple's installer script calls your default shell, probably

$SHELL -c command...

It was tested on bash but not zsh, so when zsh gets called this way, subtle shell compatibility issues arise. When you inspect the offending process (Activity Monitor unfortunately, AFAIK, doesn't show you the full commands; I use htop for this, and you may well use ps or whatever), you will see things like

zsh -c defaults delete com.apple.helpd com.apple.helpd.sdmMapsCreated

which backs my guess (well, my guess was actually derived from these observations, to be precise).* Therefore, the solution is simply run the command yourself, in this case

defaults delete com.apple.helpd com.apple.helpd.sdmMapsCreated

Then you kill the offending processes. installd automatically moves on (probably to the next stuck process like this). After multiple rounds of grinding you'll find the installation finished successfully. I know this is annoying, but this is the only way I found to work (reliably).


* It is actually beyond me how zsh -c gets stuck on things like defaults delete. Not sure if it's with my environment. (I've put GNU coreutils and alike in front of BSD stuff in my PATH, but I'm pretty sure I never messed with default.) Maybe default internally use BSD utils? But again, I can run the same command in my terminal with zsh, either interactively or non-interactively, just fine. This is really baffling (the solution above is not affected). Any input is welcome.

5
  • What a nice analysis! Thank you very much I will try that as soon as the problem arise again :-) Nov 24, 2014 at 15:14
  • The problem didn't occurs again but I really appreciated your help! Jan 13, 2015 at 16:46
  • 2
    Thanks for the pointers! To show the full process command line with standard ps tool just run ps uaxwww | grep zsh then: 1. check for what's hogging the CPU; 2. execute it manually; 3. kill the process; 4. repeat Mar 4, 2015 at 13:29
  • The -c compatibility analysis sounds right, though I can't understand either why that would get stuck, instead of just failing and returning. I'm trying to reproduce this myself. Where did you install the GNU coreutils from? And by any chance are you using a Homebrew or other non-default zsh? Jun 29, 2015 at 22:10
  • @AndrewJanke I don't know why, and I think one should probably need to read the package scripts to figure out, which I never bothered to do. My coreutils is from Homebrew (MacPorts back in the days), and my Zsh has been the stock Zsh for the most part (I recently switched to brewed 5.0.7, but the issue here has been around well before that).
    – 4ae1e1
    Jun 29, 2015 at 23:08
0

I regularly have the same issue and it's always related to the installd process, updating an AppStore application. Killing first installd and then the zsh process helps (but disables the AppStore's functionality until it's restarted).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .