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,
I have one reported user (our Dean, because of course it would be the Dean) with this issue, a MBP 2016 bound to AD. For good measure, I've wiped the drive and installed 10.12.6 – here's hoping?
Just a follow up, a fellow JAMF admin posted in MacAdmins.slack.com that gathering app usage information was handled by parentalcontrolsd. In our case, we were collecting plug-in information enabled in Computer Inventory Collection. I've turned off that configuration and users with this problem have seen a great deal of improvement. parentalcontrolsd still runs on their system but no longer consumes high CPU resources. As with others our Macs were also AD bound. So this may not address all issues listed here.
@Gonzalez, that is interesting! Have you reported this to Jamf Support maybe? Maybe they can investigate and file a Product Issue.
I've got feedback from Apple as well. The reported that the bug is a duplicate of #31942767 of therefor closed the case.
We've created the following script that will solved the issue (temporarily):
#!/usr/bin/env bash # Reset Parental Controls # # # Temp fix for macOS with high CPU on parentalcontrolsd # Delete Settings rm -fr "/Library/Application Support/Apple/ParentalControls" # Kill proces pkill -9 parentalcontrolsd
@martin Yes, I have an open case with Jamf. And I still have an open case with Enterprise AppleCare hoping to get some final resolution once Jamf comes back with an appropriate response. Others have suggested not collecting any of the software usage stats. If you collect anything in the Software configuration panel from the Computer Inventory Collection, you may need to disable.
I'm definitely seeing parentalcontrolsd spiking, and one cause for it is definitely app usage statistics gathering by the JSS.
How to reproduce:
top -uat the Terminal prompt and press return. (The top command shows the Mac's Unix process table, sorted by cpu usage and updated constantly.)
ctrl-cin the Terminal window. (This will terminate the top command. You can also quit Terminal.app if you don't need to use it further.)
Note: To trigger the cpu spike, you have to click on an entirely different app, e.g. from Safari to Mail. Switching among multiple open windows or tabs within the same app (e.g. Safari) will not trigger the cpu spike.
I recently got the problem myself (with 10.13 GM). When opening or closing Safari parentalcontrolsd was using a lot of CPU:
@Gonzalez pointed out he hasn't seen the problem when removing the Configuration Profile with a Security & Privacy payload. I've excluded my Mac from the Configuration Profile (it only contains Security & Privacy) after which I have not seen the issue. I removed my Mac from the exclusion and have seen the issue reappear.
This issue doesn't not always take place. I witnessed the issue myself now and it looks like the Security & Privacy payload causes the issue. Maybe other Jamf Nation users can confirm?
What I’ve found is that some configuration profiles cause the parentalcontrolsd process to seemingly hang. What has finally resolved this is to use more discrete configuration profiles for specific settings we want to enforce. Using something bundled like the Security & Privacy configuration profile provided by Jamf causes the problem. In our environment, a custom payload for Safari also causes the problem. For Security & Privacy, I’ve had to test each setting individually and create a custom payload. For Safari, I’ve moved to scripting preferences. Doing this has allowed the parentalcontrolsd process to shutdown shortly after boot.
I exempted myself from any login window, security, or safari config profile and was still seeing the issue. I also have all app usage,font, and plugin inventory collection disabled.
however, killing the process does work (till reboot). Will be very interested to know what the root cause/fix (if any) is.