5

Edit  In response to Tetsujin's comment, further details now are provided for reproducing the slowdown, and for reverting back to normal speed.

The usual caveat  Experimenting with system-level bugs is inherently risky. You are advised not to do so, unless you have a working understanding of users, groups, and permissions and you possess reliable system backups.

Here's a "weird trick" that instantly makes my MacBook Pro / Yosemite system run slow slow slow ... create a circular group inclusion in the Users & Groups pane of System Preferences.

Answers Sought Why does this slowdown happen? Are other users affected? Is there a tool that automatically diagnoses and fixes it? How can it be avoided in the future?

Remark After creating this slowdown inadvertently, it took me two weeks to figure out, reproduce, and repair the cause of it. The search for a fix was slow and frustrating because none of the usual fixes of "slow Mac syndrome" were effective, and none of the usual diagnostics were revealing.

Reproducing the slowdown

In the System Preferences pane "Users & Groups"

  • create new groups "a" and "b"

Close System Preferences.

Now open the Finder's "Get Info" pane for the directory at the base of a large directory tree ... for me /usr/local is large enough to elicit a severe slowdown. Then

  • under "Sharing & Permissions", give "a", but not "b", read/write privileges to all files in the tree, via the menu-selected option "apply to enclosed items".

Now reopen the System Preferences pane "Users & Groups"

  • include group "a" in group "b"
  • include group "b" in group "a"

Voila! Now everything on my MacBook runs slow ... slow ... slow. Logins require up to one minute, and even simple typing sporadically elicits the "spinning pizza." Fortunately, eliminating the circular group inclusion instantly restores the system to its former speed.

Returning to normal speed

To revert the changes, reverse the above steps

  • first undo the group "a" and group "b" circular inclusions
  • then remove the group "a" read/write permissions
  • then delete groups "a" and "b"

Hypothesis Yosemite's bash shell performs poorly in resolving circular group references when searching large directory trees in "$PATH" variables.

Evidence Even simple command-lines like "ls" run slowly ... it appears that when circular group inclusions are present, bash is slow in searching $PATH to locate the "ls" file.

System Software Overview:

System Version: OS X 10.10.2 (14C109)
Kernel Version: Darwin 14.1.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Computer Name: [redacted]
User Name: [redacted] (Administration)
Secure Virtual Memory: Enabled

Hardware Overview:

Model Name: MacBook Pro
Model Identifier: MacBookPro11,3
Processor Name: Intel Core i7
Processor Speed: 2.5 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 16 GB
Boot ROM Version: MBP112.0138.B14

Note also that /usr/local tree is fairly large (as is typical of developers and LaTeX users) ...

$ find /usr/local -type f | wc -l
204713
John Sidles
  • 161
  • 1
    I'm surprised it manages to work at all with circular refs, infinite recursion. I'd guess there is some check that prevents it just infinite looping & slewing to a total halt. – Tetsujin Feb 14 '15 at 14:41
  • Tetsujin, there's no infinite recursion (as it seems to me), because asserting that both "members of group 'a' are in 'b'" and "members of group 'b' are in 'a'" amounts to "'a' and 'b' are the same group". This assertion is entirely valid, and hence it's OK that the "Users & Group" pane allows this specification. Hmmm...perhaps my post might better have called them "group identities" rather of "circular inclusions"! So what's not OK is that Yosemite parses group identities so dreadfully slowly, that users can suffer indefinitely from a valid group identity that takes one click to assert. – John Sidles Feb 14 '15 at 15:08
  • 1
    Have you tried making a group c & adding a & b as members of that instead of members of each other. – Tetsujin Feb 14 '15 at 16:55
  • No ... I'll leave these details to (hopefully) Apple engineers! The bug (perhaps) arises from assuming that group inclusions are structured as a tree of inclusions ... when (sometimes) they're structured as a (more general) graph of inclusions. – John Sidles Feb 14 '15 at 17:51
  • 1
    I tried your specific setup; didn't slow anything down, but it never resolved the group name in a Get Info floater, whether I opened & closed, or left it thinking for 20 mins, just said 'Fetching…' It does seem a very special case of intersecting sets, a is entirely in b & b is entirely in a. – Tetsujin Feb 14 '15 at 17:55
  • 1
    The question now gives complete instructions for replicating (and reverting) the slowdown ... thank you, Tetsujin, for your help! – John Sidles Feb 20 '15 at 00:35

0 Answers0