Posted on 04-22-2016 07:02 AM
Hello all, I have ~150 Macs all bound through our AD, and also configured using Profile Manager. I don’t have anything out of the ordinary configured (Software Update, Munki URL, Screen Saver/Screen Lock) through profile manager, but I have several users with the parentalcontrolsd process either spiking their CPUs constantly, or in a couple cases, using ~6 GB RAM.
Anyone seen this issue or hopefully have a fix? Thanks so much in advance,
Posted on 04-22-2016 07:05 AM
We actually have been experiencing this issue recently where a reboot would resolve this issue temporarily but then come up again after a few days.
What seems to fix this for us was to apply Energy Saver settings to not allow computers / hard drive to sleep.
Posted on 04-22-2016 11:10 AM
not allow computers / hard drive to sleep
Thanks for the reply. Are you saying to not allow the computer and HDD to sleep?
Any idea what the root cause is? Feel like there are to few users for this to be a bug, maybe something we are doing wrong.
Posted on 04-22-2016 11:26 AM
I've tested this with an out of the box Mac with just the OS (10.11.1) and a config profile with restriction payload settings applied and bound to AD. I noticed after waking the computer from sleep the memory usage would increase little by little each time and would also cause the CPU to spike and eventually become unusable after a few days.
I've also had 2 other test Macs running at the same time with the same config profile except with the Energy Saver settings listed above and they did not experience this issue. It took around 3-4 days to start seeing the issue occur.
Posted on 04-22-2016 12:36 PM
I've been seeing this same problem for months but I have no explanation for it. The weird thing is it only seems to happen on a couple Macs, but it is always the parentalcontrolsd process. Users who report it say restarting their computer seems to make it stop... until the next time it happens. Unfortunately We need to set energy settings to let the computers sleep.
Posted on 04-22-2016 02:57 PM
Someone mentioned on Slack that Apple have seen this & are working on a fix.
Please log bugs with Apple so they know it's affecting you.
Posted on 04-27-2016 07:05 AM
@AVmcclint I think the reason you're only seeing this on a few devices may be because either the Macs are not constantly on or they're not reporting the issue. We originally thought it was only a few Macs experiencing this, but we're getting more and more reports of this issue occurring.
Posted on 04-27-2016 02:09 PM
Posted this in another thread just now also, but our fix has been to turn off parental controls.
launchctl unload -w /System/Library/LaunchDaemons/com.apple.familycontrols.plist
Once we run that via policy it hasn't been reported again as an issue.
Posted on 05-14-2016 01:59 PM
This is related to all instances of com.apple.applicationaccess.new.plist under /Library/Managed Preferences/. I've taken a look and all affected machines have parental controls explicitly disabled - if the setting is unenforced, parentalcontrolsd does not exhibit high cpu usage.
Guessing this is being distributed by Security & Privacy or Login Window (or Restrictions) payloads.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadUUID</key>
<string>37D106F1-D4A2-42DA-AD2A-F186AC338537</string>
<key>_manualProfile</key>
<true/>
<key>familyControlsEnabled</key>
<false/>
</dict>
</plist>
I don't recommend this but it can be used as a temporary fix of sorts. https://gist.github.com/opragel/acf1e4661fac6d66745e9f781a89514e#file-tempfix_managedpref_parentalco...
Posted on 08-10-2016 06:11 AM
Any further information on this issue as one of our devs is seeing the same problem?
Posted on 08-14-2016 11:28 PM
@nycnewman I've seen much better performance since upgrading to 10.11.6, can anyone else confirm?
Posted on 08-16-2016 05:25 AM
My user is on 10.11.6 and still seeing issues. No longer with Parental Controls process but others. Only occurs when machine goes into Sleep mode.
Posted on 08-16-2016 05:44 PM
@nycnewman What other processes are you seeing? What model hardware is the problem occurring on?
Posted on 08-16-2016 06:39 PM
no longer parentalcontrolsd. now socketfilterfw, kernel_task (catch all), and accountsd
Mac Pro Mid 2015 15inch running 10.11.6
On support's request we enabled a policy that disabed parentcontrolsd
Posted on 08-17-2016 04:34 PM
Wondering if anyone on this thread has an Apple Radar ID for reference on this behavior?
Posted on 08-22-2016 04:07 AM
FWIW, saw this today.
I combined some payloads for the customer, as per this, & after a reboot things seem to be resolved.
Posted on 09-27-2016 10:21 AM
Hi,
I'm seeing this too - even on Sierra. Would love a Radar ID or any tips people have found that does the trick
Thanks!
Matt
Posted on 09-28-2016 02:52 AM
@mbezzo I followed bentoms article which did the trick.
Posted on 12-07-2016 06:37 AM
@bentoms Hey Ben, we've tried that method as well and confirmed the issue still occurs after some time. It takes sometimes 2-3 weeks to build up and start spiking. A reboot will temporarily fix it until it starts building up again. It's difficult to test a solution for this since it takes time to see if it starts building up again. Some of our users restart their Macs regularly or do not have their Macs go to sleep often (this is when it seem to build up), so they don't notice this as much.
Posted on 02-06-2017 07:08 AM
We are seeing this in our environment on machines running 10.12.2, restart is a temp mitigation but it builds back up after a few days.. anyone been able to resolve this?
Posted on 02-06-2017 08:17 AM
Still an issue in 10.12.3! I really hope this can be fixed. It only seems to be effecting select computers at this point, it would be nice to know the cause of this.
Posted on 02-10-2017 05:40 AM
Followed @bentoms article, found the items mentioned and created new profiles but issue is still present. Only select computers as well.
Posted on 02-17-2017 09:19 AM
I checked with AppleCare Support today. The response was, known and test 10.12.4 beta to see if it's resolved.
Posted on 02-21-2017 06:14 AM
I've tested with 5 machines that exhibit the parentalcontrolsd CPU churning issue under 10.12.4 beta and 3 of the four continued to exhibit the behavior. The other two are VM's and I'm going to let them run for a while. I suspect that after some period of time I'll see them ramp up CPU usage as well. I'm filing a bug report with Apple this morning against the beta.
Posted on 02-24-2017 11:26 PM
Multiple users are reporting the issue in my environment. I've also been experiencing it on my 13" retina MBP. Hopefully 10.12.4 alleviates this issue.
Posted on 04-19-2017 10:53 AM
How are you able to run that command when SIPs is enabled? Or, do you have it disabled in your environment?
Posted on 05-04-2017 12:00 PM
Does anyone have any successful experience running the command below in Sierra 10.12.4 with SIPs enabled? I used to run said command successfully prior to 10.12.4 but it no longer works. I also have end users where parentalcontrolsd is running the CPU hot even with Parental Controls disabled, including the Guest account.
launchctl unload -w /System/Library/LaunchDaemons/com.apple.familycontrols.plist
Posted on 05-04-2017 12:33 PM
This is jank, but it will work (until the next reboot).
#!/bin/bash
pkill -STOP parentalcontrolsd
Posted on 05-04-2017 02:09 PM
@ owen.pragel
I'll give it a shot and will post back results.
Posted on 05-11-2017 05:04 AM
Hi, I'am running on macOS 10.12.4 and still have issue with parentalcontrolsd.
Posted on 05-12-2017 07:49 AM
I'm seeing this as well. Have an open case with Apple and will be submitting some logs/information today. Running 10.12.4, no AD.
Posted on 05-15-2017 12:12 PM
Unfortunately, I'm still experiencing issues with parentalcontrolsd running hot. Again this is on 10.12.4, no AD and I've used the following scripts with no success.
Script 1 (this worked before 10.12.4):
launchctl unload -w /System/Library/LaunchDaemons/com.apple.familycontrols.plist
Script 2 (no success):
pkill -STOP parentalcontrolsd
@tanderson Please let me know if you receive any updates with your Apple ticket.
Posted on 05-16-2017 11:17 AM
I am experiencing this as well. Just noticed it today on my machine. I am bound to AD on 10.12.4. Thinking about upgrading to 10.12.5 to see if it gets fixed.
Posted on 05-16-2017 11:49 AM
Upgraded to 10.12.5 last night and while it's way too soon to say for sure I haven't seen the issue yet today. We'll see.
Posted on 05-16-2017 11:52 PM
@ocapetillo Even after running
sudo pkill -STOP parentalcontrolsd
you are seeing high CPU usage from the process? Halting the process won't persist through reboots, so if you want to use that technique you'll have to do the needful to ensure it runs when appropriate.
Never said it was pretty. This issue is clearly the result of a bug in macOS from what I understand - see ActivityTracker appDidLaunchOrBecomeFront.
Posted on 05-17-2017 07:40 AM
I'm running "sudo pkill -STOP parentalcontrolsd" as a script that triggers at Jamf inventory check-in, user login, start up & network state change via a Jamf policy. That way even after a reboot, the script / policy triggers again. However my end users are still reporting that parentalcontrolsd is still running CPU resources high. I'll need to reconfirm this myself as I just pushed this policy / script two days ago.
I used to be able to run "launchctl unload -w /System/Library/LaunchDaemons/com.apple.familycontrols.plist" as a script prior to 10.12.4, using the same Jamf parameters mentioned above, and it worked flawlessly. Unfortunately this script stopped working when upgrading to 10.12.4 and I believe this is a result of SIP.
I have NOT tried disabling SIP and launching any of the above scripts but it might be my next step if I can't figure it out with it enabled.
Posted on 05-21-2017 10:54 AM
Just to follow up on my post from 5/17/17. The issue still exists in 10.12.5. It took several days but the high CPU usage has returned.
Posted on 06-19-2017 07:03 AM
Going to chime in and say this is till happening on my machine as well with 10.12.5. Anyone found a viable fix?
Posted on 06-20-2017 04:30 PM
We have a few 10.12.5 systems with this problem and an open case with Apple Care. Does anyone have a method to reproduce the problem consistently?
Posted on 06-29-2017 11:55 AM
Just piping in to get updates on this thread. Have a user with the same issue.