Ever since upgrading to 9.4, we have seen the jamfAgent process on our clients slowly start to eat up more and more CPU. Eventually it reaches anywhere from 30-55% constantly. If we unload and reload the LaunchDaemon, the CPu usage returns to normal for a little while, but eventually it will slowly crawl back up to 30-50% CPU.
I have an active support case open, but I was wondering if anyone else had seen this behavior. Another thing that I found interesting is that running:
sudo fs_usage -w | grep "jamf"
showed that the jamfAgent process was constantly running sw_vers over and over again multiple times per second. Is anyone else seeing this behavior?
Interesting. jamfAgent pre 9.4 was the version that had the false "Not responding" issue under Mavericks. This was noted as fixed in the 9.4 release notes. I wonder if whatever changes they made regarding the jamfAgent are causing the high CPU utilization?
It would suck if so. I'd rather have the false not responding issue over high CPU utilization.
Agreed. Thanks Colonel!
And, I hate to even bring this up because I know it initially sounds like bashing, but honestly, issues like this one are exactly why we need Feature Requests like this to be taken seriously: https://jamfnation.jamfsoftware.com/featureRequest.html?id=2345
For all the great stuff that came with 9.4, the last thing anyone wants is for the jamfAgent or any other jamf related processes to start eating up resources and causing performance problems on our managed devices. We get questioned constantly by our tech savvy users as to why they continuously see the jamfAgent showing up as "Not responding" in Activity Monitor on their Mavericks Macs. They see this when they start having performance issues and immediately think its the agent that's at fault, when its not.
The fix for the false jamfAgent issue should really have been rolled into a specific 9.3<something> release, prior to 9.4 and the new features. That way maybe it would have been caught and addressed before all the great new items 9.4 brought. As is, issues like this can actually negate some of the good stuff, which is not what anyone wants, least of all JAMF.
I'll just state that I'm making an assumption here that could be incorrect. The assumption that the "fix" for the jamfAgent not responding issue is part of the cause here. It may turn out not to be that at all (in which case I'll gladly retract parts of my post here). But given the jamfAgent was updated to address that specific issue in 9.4, logic would seem to point to the fact that the updated version has a bug in it.
We'll just have to wait and see what JAMF has in the works to address this. Even if it turns out to be unrelated, I still see the need for bug fix only releases.
Extremely glad I saw this before going to 9.4 this weekend. It really seems like JAMF is putting too much emphasis on new features and not enough resources into getting things right. Maybe a case of growing too fast or just not enough developer talent in the Midwest? Either way there have been far too many defects in the latest releases for comfort.
Casper is still the best tool out there but lately it's been feeling like Quark did around versions 7.5 and 8. Still great but many annoying oversights in execution.
It appears to be resolved for me as well with 9.5. However, thanks to @colonelpanic, i'm now curious about what the agent is doing in the background with the command:
fs_usage -w | grep "jamf"
I see these three lines pop up every two or three seconds over and over. I don't have file vault turned on on this client.
/Library/Application Support/JAMF/run/file_vault_2_id.xml /Library/Application Support/JAMF/file_vault_2_id.xml /Library/Application Support/JAMF/file_vault_2_recovery_key.xml
Those xml files are used to store the recovery key when FV2 is enabled on a Mac from a disk encryption configuration out of Casper and get picked up by an inventory collection process. Though I haven't seen the "run/file_vault_2_id.xml" file before. May be something new?
If FV2 hasn't been enabled on that Mac, that's very curious that it would be looking for those files, unless its done on purpose to scoop those up into the db as soon as they are spotted.