9.9 and 9.91 Quick Add causing Spotlight CPU run at 130%

[CorpTech]

I don't know if anyone else has experienced this, but any computer that we enroll with 9.9 or 9.91 causes the Spotlight process to jump to 130% and never go back down. We thought it was an indexing error, but I spent about 90 mins on the phone with Apple Enterprise Support and they couldn't figure it out either. I tried making a new image, removing programs, and uninstalling the antivirus. Open when we removed the Jamf framework did the problem go away. Had to roll back 9.82 for everything to go back to normal. I told our TAM and it seems that this may be a known issue. Just wondering if this has popped up for anyone else.

[robby_c137]

Same! Fans full blast.

Thought it was 10.11.4 so I spent a lot of time rebuilding spotlight, running maintenance and reinstalling OS X with no success.

Two of our users have reported the issue but who knows how many users are just unaware of it and letting their Macs get hot.

[MrP]

I noted spotlight running at 130% yesterday. Completely wiping the index didn't help. Neither did excluding the entire system drive and unchecking all item types to index. When this is happening spotlight doesn't try to re-index. Also tried removing /.Spotlight-V100. All of this with reboots of course.

Found by removing /Library/Managed Preferences/com.apple.Spotlight.plist and /Library/Managed Preferences/*/com.apple.Spotlight.plist, then doing a "killall Spotlight" allowed spotlight to re-index and use nominal CPU.

I checked my managed preferences in casper and saw no reference to spotlight at all. I did "jamf mcx" and "jamf mcx -username MYNAME" which brought those plists back down. After restarting spotlight the problem came back. Removing those plists and restarting spotlight resolved it again.

I'm using the following script to refresh the managed preferences on systems periodically and have appended removing the uneeded and problematic spotlight plists.

# Setting this variable, "field splitting" makes sure each line is considered as such, even with spaces in them.  
#  Otherwise spaces are considered splitters.  Here we are specifying "
"(page break) is the only splitter.  
IFS=$'
'

echo Deleting all managed preference files...
rm -rf /Library/Managed Preferences/*
echo Deleting all computer level managed preferences from the local directory.. 
dscl . -mcxdeleteall computers/localhost
a=`ls -d /users/* | cut -d "/" -f 3`
for userfolder in $a
do
    if [ "$userfolder" != "Shared" ];
    then
        echo Deleting all user level managed preferences from the local directory for user: $userfolder
        dscl . -mcxdeleteall users/$userfolder
    fi
done
/usr/local/bin/jamf mcx
for userfolder in $a
do
    if [ "$userfolder" != "Shared" ];
    then
        /usr/local/bin/jamf mcx -username $userfolder
    fi
done
jamf manage


killspotlight="no"
if [ -e /Library/Managed Preferences/com.apple.Spotlight.plist ]; 
then 
    echo "System: Spotlight Managed Pref Plist found.  Removing..."
    rm -rf /Library/Managed Preferences/com.apple.Spotlight.plist
    killspotlight="yes"
fi
for i in `ls -d /Library/Managed Preferences/*/`; 
do  
    if [ -e $i/com.apple.Spotlight.plist ]; 
    then 
        echo "System: Spotlight Managed Pref Plist found in $i  Removing..."
        rm -f $i/com.apple.Spotlight.plist
        killspotlight="yes"
    fi
done
if [ $killspotlight == "yes" ]; then killall Spotlight; fi


exit 0

[CorpTech]

My TAM is going to escalate this up. One thing to note though, clients that check in and update their binary are fine. Just newly enrolled machines.

[emily]

We've had this going on at our org too, mostly newly-provisioned machines but a handful of previously deployed machines as well. It does seem to line up with updating to 9.91.

Mine has been running at 150% CPU for about a week now. Every once in a while it runs up the fan. SMC reset, NVRAM reset, killing processes, flushing system/user cache, killing the process in Activity Monitor… none of that seems to help.

Has anyone tried removing the Framework and re-enrolling to see if that fixes it, if it really is a binary issue causing this problem?

ETA: I'm seeing in the initial post that removing the framework does appear to fix it, weird. I'll try unenrolling/re-enrolling and see if it starts up again for me. Odddddddd

[rderewianko]

We've seen it on 9.9 and 9.91

While removing the framework does solve the problem its not a solution.
We also found removing a config profile that contained screensaver settings also helped. We have yet to try running the above.

[MrP]

Has everyone tried locating all instances of com.apple.Spotlight.plist on their system and done a 'defaults read' on them to see what they say?

FWIW, when I did "defaults read /Library/Managed Preferences/com.apple.Spotlight.plist", defaults seg faulted. It did this after I removed the file and refreshed mcx from the jamf server as well. Considering the problem is with spotlight, spotlight configs are probably a good place to start looking for anything that stands out. For me, between the reproducible segfault and not having any managed preferences pertaining to spotlight configured on the JSS, yet still getting assigned spotlight plists under managed preferences, that stood out to me.:)

[mike_paul]

Just an FYI, you will want to just remove the spotlight and submit diag info profiles and NOT do the full rm -rf of /Library/Managed Preferences/ due to many OS X Configuration Profiles actually using MCX plists to apply settings. Some commonly used ones are login window, screen saver, FileVault redirect along with many others. But even though Configuration Profiles use the MCX plists, they aren't being pushed by the MCX framework of the JSS so the "jamf mcx" wont bring down the settings again.

The ones that appear to be the culprits for the cpu spike are:
/Library/Managed Preferences/com.apple.Spotlight.plist /Library/Managed Preferences/<username>/com.apple.Spotlight.plist
/Library/Managed Preferences/com.apple.SubmitDiagInfo.plist /Library/Managed Preferences/<username>/com.apple.SubmitDiagInfo.plist

Also upon logout/login these plists are recreated so the problem would likely return.

In regards to reapplying settings removed that you wished to have there, the inventory collected by a recon only reports on Config Profiles being installed, not their corresponding plists they lay down. So any subsequent inventory submission wouldn't tell the JSS to resend the profile with the corresponding plist because technically its still installed. You would most likely have to remove the profile from the scope of the device and reapply if you didn't wish to have the users log out and log back in.

I would recommend contacting support as they have some workflows to help resolve this issue in a more permanent manner.

[CasperSally]

Is there a defect number on this Spotlight issue?

[wgregorian]

It happens as soon as we apply the Security & Privacy profile payload. For the love of God, this is the dumbest issue ever. Is JAMF aware of this problem?

[mariobarrera]

We saw the same thing if we removed a Security & Privacy profile it works fine.

[CasperSally]

Is there a defect number on this issue? Seems like a big one.

[wgregorian]

All,

It's not the Security & Privacy profile, though that triggers the issue. The problem is with the restrictions, specifically, " Allow iCloud documents & data" and " Allow use of iCloud password for local accounts" are the two keys that cause this. These were introduced in version 9.9 from what I can tell, and those are exactly the two that's causing this problem. That said, JSS is rewriting the key values in the payload, so the only way to fix it is to use the OS X server profile manager to create your own, sign it, and then upload it to JSS.

That fixed our problem (~53 Macbooks) immediately.

YMMV.

[were_wulff]

@CasperSally & everyone else,

We have it filed under PI-002155.

We've found that the most reliable workaround in this case, as @william.gregorian mentioned in his post, is to use Profile Manager to create the profile that needs the Security and Privacy payload, export it signed, and then import it to the JSS and deploy it. It is important that the profile is signed when exported, or the problem will likely come back after the profile is uploaded to the JSS and deployed.

If you find you need assistance with the workaround or have additional questions, please get in touch with your Technical Account Manager by giving them a call, sending an e-mail to support@jamfsoftware.com, or by using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support

[dgreening]

Lets hope that this is fixed in 9.92!

[CasperSally]

I hope it's fixed in 9.92 as well. We really want to implement home screen layout and lock screen iOS payloads in 9.9x but this is too big a bug to deal with. I appreciate profile manager provides a work around, but ideally it's fixed in 9.92 so not necessary.

[GabeShack]

I'm now wondering if this relates to the white screen issue I'm seeing on our Library iMacs after it boots up with fans spinning. I had recently added a security profile to them....
Thread:
https://jamfnation.jamfsoftware.com/discussion.html?id=19714

Gabe Shackney
Princeton Public Schools

[MrP]

For us it doesn't matter if the restrictions payload has the iCloud checked or not.

I did the following while applying each. I start with no abnormal Spotlight CPU usage. I also programmatically delete the com.apple.Spotlight.plist's via a script that runs on every checkin, so when I run the following it returns "no such file or directory" as you would expect. As soon as I apply a configuration profile containing the payloads Retrictions, Login Window, and Security & Privacy, the command shows the files are created. I removed them then reproduced these results several times to make sure it wasn't coincidence.

M-USER01:~ ACCOUNT$ while [ 1 == 1 ]; do ls /Library/Managed Preferences/*Spot*; ls /Library/Managed Preferences/*/*Spot*; sleep 1;done
ls: /Library/Managed Preferences/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*/*Spot*: No such file or directory
ls: /Library/Managed Preferences/*Spot*: No such file or directory
/Library/Managed Preferences/USER/com.apple.Spotlight.plist
/Library/Managed Preferences/com.apple.Spotlight.plist
/Library/Managed Preferences/USER/com.apple.Spotlight.plist
/Library/Managed Preferences/com.apple.Spotlight.plist
/Library/Managed Preferences/USER/com.apple.Spotlight.plist
^C
M-USER01:~ ACCOUNT$

After doing this and seeing those re-created I did "sudo killall Spotlight". The new spotlight process instance launched as a result takes 130% cpu. I then manually remove those files and kill spotlight again. The new spotlight process instance takes nominal cpu usage.

Is it normal for a Configuration Profile payload to create a plists in the managed preferences folder? I've always assumed that was a function/result of any configured Managed Preferences settings.

[CasperSally]

@MrP

Yes, config profiles create plists in managed preferences folder.

[MrP]

Here is what I put in my script that runs on every check-in. A lot easier than messing with exporting/importing the profiles.

##
# Spotlight: Fix spotlight cpu issue
##
IFS=$'
'
killspotlight="no"
if [ -e /Library/Managed Preferences/com.apple.Spotlight.plist ]; 
then 
    echo "System: Spotlight Managed Pref Plist found.  Removing..."
    rm -rf /Library/Managed Preferences/com.apple.Spotlight.plist
    killspotlight="yes"
fi
for i in `ls -d /Library/Managed Preferences/*/`; 
do  
    if [ -e $i/com.apple.Spotlight.plist ]; 
    then 
        echo "System: Spotlight Managed Pref Plist found in $i  Removing..."
        rm -f $i/com.apple.Spotlight.plist
        killspotlight="yes"
    fi
done
if [ $killspotlight == "yes" ]; then killall Spotlight; fi

[Apfelpom]

Thank's all & @MrP: very helpful script!

[robby_c137]

@MrP I'm getting this error frequently. Any ideas on how to tweak it so it doesn't fail as much?

Actions from policy log: Executing Policy Spotlight CPU temp fix Running script spotlight-mcx-removal.sh... Script exit code: 1 Script result: System: Spotlight Managed Pref Plist found. Removing... System: Spotlight Managed Pref Plist found. Removing... No matching processes were found Error running script: return code was 1

.

[MrP]

@true[robby] See changed script above.

[MrP]

DELETED

[robby_c137]

Clever! Thanks @MrP!

[yellow]

@MrP

THANK you. In my testing this is working well.

[bentoms]

Looks like another fix here.

[bentoms]

FWIW, delved into this issue this AM & the one linked above.

I have posted my findings here.

[bentoms]

dupe

[znilsson]

Just wanted to add that @bentoms solution worked for me. I had already combined my Login Window and Security & Privacy payloads into one config profile to solve the "screen doesn't lock immediately" issue, so I just added the Restrictions payload, distributed and rebooted my test machines (both of which had high Spotlight CPU usage), and they were both fixed after that. Thanks for the detailed info, @bentoms .

[bentoms]

@znilsson cool!

@owen & @rderewianko (think that's their nicks here) helped massively too.

As did @davidacland's Automator service. :)

[MrP]

I have had all three payloads combined since last year and the issue still occurs for me under that configuration. FWIW.

[bside]

Have been fighting with this today, it seems that you have to have "Allow Spotlight Suggestions" checked to fix the issue. When unchecked it creates the com.apple.Spotlight with the MCX for "parsecEnabled" and Spotlight jumps back to 100%. Requires a reboot after applying. Thanks @bentoms for the writeup here: https://macmule.com/2016/05/09/icloud-spotlight-login-window-issues-with-jss-9-9-the-security-privacy-profile-payload/#Back_To_The_Start !

[bentoms]

@MrP is "allow spotlight internet results" (or whatever it is), checked under restrictions?

[MrP]

Nope. We won't enable it either as it is possible for data leakage to occur. I don't want to be the one responsible for HR to be searching for a document containing an SSN and "John Doe", and have that information sent out across the wire. No thanks.

[bentoms]

@MrP well, that's why this issue persists.

You need that option checked.

[bpavlov]

OS X 10.11.5 might address part of the issue: https://support.apple.com/en-us/HT206230

[znilsson]

Sure looks like it. Nice catch, @bpavlov . I'll see about loading 10.11.5 onto a test Mac and then de-coupling the restrictions payload from my combined config profile and see if the spotlight problem comes back.

[yellow]

Installed 10.11.5 on a couple devices and Spotlight is behaving as expected.

[dgreening]

Anyone know if 9.92 helps to address this issue?