Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

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

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.

Like Comment
Order by:
SOLVED Posted: by true[robby]

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.

Like
SOLVED Posted: by 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 "\n"(page break) is the only splitter.  
IFS=$'\n'

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
Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.:)

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by CasperSally

Is there a defect number on this Spotlight issue?

Like
SOLVED Posted: by 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?

Like
SOLVED Posted: by mariobarrera

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

Like
SOLVED Posted: by CasperSally

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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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

Like
SOLVED Posted: by dgreening

Lets hope that this is fixed in 9.92!

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by gshackney

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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by CasperSally

@MrP

Yes, config profiles create plists in managed preferences folder.

Like
SOLVED Posted: by 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=$'\n'
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
Like
SOLVED Posted: by Apfelpom

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

Like
SOLVED Posted: by true[robby]

@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

.

Like
SOLVED Posted: by MrP

@true[robby] See changed script above.

Like
SOLVED Posted: by MrP

DELETED

Like
SOLVED Posted: by true[robby]

Clever! Thanks @MrP!

Like
SOLVED Posted: by yellow

@MrP

THANK you. In my testing this is working well.

Like
SOLVED Posted: by bentoms

Looks like another fix here.

Like
SOLVED Posted: by bentoms

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

I have posted my findings here.

Like
SOLVED Posted: by bentoms

dupe

Like
SOLVED Posted: by 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 .

Like
SOLVED Posted: by bentoms

@znilsson cool!

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

As did @davidacland's Automator service. :)

Like
SOLVED Posted: by MrP

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

Like
SOLVED Posted: by 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 !

Like
SOLVED Posted: by bentoms

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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by bentoms

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

You need that option checked.

Like
SOLVED Posted: by bpavlov

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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by yellow

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

Like
SOLVED Posted: by dgreening

Anyone know if 9.92 helps to address this issue?

Like
SOLVED Posted: by emily

10.11.5 fixed it for us. Haven't scanned through the release notes for 9.92 to see if JAMF also addressed it or not.

Like
SOLVED Posted: by bentoms

@dgreening 10.11.5 resolves.

Like