@thoughton, 10.9.1 here and 9.23, no issues though that piece is still showing as not responding. We've seen no negative impact.

Thanks for all the responses. There doesn't appear to be any issue with this, but who knows. Sometimes an issue exists that isn't really effecting anyone, and then we see it in the release notes of the next version. Good to know it's not just us this is happening to. We tested on 10.9.1 / 9.23 and are also still seeing it. Spurious error I suppose (or hope). :)

We are still seeing this issue in 10.9.2 JSS 8.73.

Confirming Armando's post, I'm also seeing this on 10.9.2 with JSS 8.73.

I also noticed that my Self Service policies don't actually run until I have force quit the jamfAgent (if it is in the "Not Responding" state). I click on an SS policy and the progress bar just zips across but nothing actually happens.

This could be a deal breaker on moving my users to Mavericks. Is there any further response from Apple on getting their bug resolved? Any workarounds we can use in the meantime?

On Mavericks 9.2 base image, this is still occurring. Casper Suite 9.3 as well.

Hey all,

Thanks for all the updates in this thread!

This one is actually something we have our own defect (D-005179) open for, as well as an Apple RADAR (15251157).

It’s an issue between Mavericks and the jamfAgent. We use AppKit within the jamfAgent, and the OS treats it like a GUI app; therefore the jamfAgent becomes subject to Not Responding status in Activity Monitor.

The end result is that Activity Monitor incorrectly shows that the jamfAgent process is not responding.

Our defect is still open, and our devs are tracking the Apple RADAR bug as well, while they work on a fix for it.

If you have any additional questions regarding this, it would be best to reach out to your Technical Account Manager so we can get it documented and tracked from our end.

Thanks!
Amanda Wulff
JAMF Software Support

I just upgraded to the preview for 10.9.3 and I am having this problem. I don't know if I had it prior. Restarting didn't help nor did quitting the process.

jamfAgent (Not Responding) 3.4MB 4 threads 66 ports PID: 444 user: root

jamf itself runs separately in the black with 4.6 MB 4 threads and 67 ports PID 102 user: root

update:

I quit the process after another restart and it stayed black for the first time—for about a minute, starting with two threads. It then went up to 4 and then back down to 2. Then it went back to 4 and turned red (not responding).

@sauer

This is still mentioned in the 9.25 release notes as a Known Issue with OS X v10.9.

My 10.9.2 machine exhibits the issue with Casper 9.25

Quick update as it doesn't seem like anyone posted any details about the effects of this issue.

I'm at a large org (NDA can't say where ) using Casper and I'm having issues moving files from local directories. Particularly using the command line seems to be an issue. Seemingly simple commands like cp and mv start moving files, hang, and then you can see the jamfagent 'not responding' in the activity monitor.

Hi @Vann ,

I did actually post an update to this back on 4/1in this thread, but for reference, I'll paste it again here:

This one is actually something we have our own defect (D-005179) open for, as well as an Apple RADAR (15251157).

It’s an issue between Mavericks and the jamfAgent. We use AppKit within the jamfAgent, and the OS treats it like a GUI app; therefore the jamfAgent becomes subject to Not Responding status in Activity Monitor.

The end result is that Activity Monitor incorrectly shows that the jamfAgent process is not responding.

Our defect is still open, and our devs are tracking the Apple RADAR bug as well, while they work on a fix for it.

If you have any additional questions regarding this, it would be best to reach out to your Technical Account Manager so we can get it documented and tracked from our end.

The only effects we've found in testing are that it shows up as not responding when it should not, and that is due to an issue with OS X, for which there is an open RADAR.
Some users have noticed that Self Service policies seem to not run until the process is killed and allowed to respawn, but we have not been able to reproduce that in house.

The jamfAgent not responding is likely a coincidence to the other issues you're experiencing, and I'd recommend getting in contact with your Technical Account Manager to dig in deeper.

You can do that by sending an e-mail to support@jamfsoftware.com, giving our support line a call, or using the My Support section of JAMF Nation.

Thanks!

Amanda Wulff
JAMF Software Support

Thanks Amanda. I'll keep note of the issue and see if it keeps cropping up. Is there any way that I could conclusively test my hypothesis that the jamfagent may be preventing the file movement?

Hey @Vann ,

The easiest way I can think of to test would be to take a machine that is not being managed by the JSS and try the same sets of commands to see if the behavior appears.

If we don't have a machine that's currently unmanaged, we can unmanage a test machine by running a sudo jamf removeFramework in terminal and rebooting.

If the behavior doesn't reappear, it's not a guarantee that it's the jamfAgent process as there may be other things going on after a computer is enrolled into the JSS (policies, scripts, MCX settings, config profile settings, etc...) that could cause strange behavior, but it can at least help with narrowing it down.

I do know in 10.9.x there are some issues with AFP that can cause incredibly slow-to-the-point-of-unusable file transfers between shares, and that is a known issue with Mavericks that tends to be (unfortunately) intermittent, so that may be another thing to look into if the computers that are showing symptoms are also running Mavericks and we're attempting to copy across network shares.

If it's local copying, the best next place to look would be in the system.log on an affected computer; there may be helpful info or errors in there.
I know it sounds a bit silly, but usually one of the first things I do when one of my Macs starts acting up oddly like that, especially when trying to move things between local folders, access settings, or just plain seeming 'off', is to run a quick disk permissions repair and see if it clears it up.

If we're still seeing the behavior after all of that, we'd want to start looking at the system.log and jamf.log from an affected machine as well as the JAMFSoftwareServer.log from the server; those are things we'd want to send in to your Technical Account Manager on a case if it moves on to that point. These would be three files we'd want to send over with a case, though our ticket e-mail system will reject files over 10MB in size; if your log files are larger in size (combined or singly), just ask, in the ticket, for your Technical Account Manager to send instructions to you on how to send us larger files and they'll be able to get that going for you.

If you do open up a case, please feel free to reference this JAMF Nation thread in the e-mail; the more information your Technical Account Manager has to start with, the better.

Thanks!

Amanda Wulff
JAMF Software Support

@amanda.wulff: Has there been any progress on this? Every time a desktop analyst has an issue with a Mac, they send us a screenshot of the jamfAgent in Activity Monitor and want to blame this. I send out the info you posted on the Apple Radar report and let them know it's not related, but it would be nice to have this one go away.

Thanks,
Scott

@boettchs Sounds like a Desktop Analyst training issue. Point the techs to this thread?

@donmontalvo: It is, sorta. In our environment, there's a bit of "buck-passing" and this is the sort of thing that yes, I do send them info on why it's not the issue, but when these guys and gals want to look good, they scream it's a problem they can't fix because of "Casper". It's just one headache I'd like to go away. But in the end, it's just that - edumacation. Until it's fixed :)

@boettchs

This was fixed in 9.4, though 9.4 introduced another issue with the jamfAgent eating up 40-60% CPU all the time, so I can't say I'd recommend going to 9.4 for that reason alone.
That high CPU usage issue was fixed in 9.5, and should still be fixed in 9.51, however, 9.51 has some pretty significant issues with MySQL 5.5 (meaning 'the JSS will crash every couple of minutes') so in the event that you're using MySQL 5.5 in your environment we'd want to either:

1) Upgrade to MySQL 5.6 prior to upgrading to 9.51. The issue is specific to MySQL 5.5.

2) Wait for 9.52, as the defect with MySQL 5.5 should be taken care of in that release. We don't have a concrete release date for 9.52, but I do know the hope was that it would be out sometime this week, though I obviously can't guarantee that will be the case.

If you're still seeing the jamfAgent not responding in 9.5 or 9.51, please get in touch with your Technical Account Manager ASAP to let them know so we can double check and make sure the devices have the correct jamf binary version.

Thanks!
Amanda Wulff
JAMF Software Support

@amamda.wulff thanks for this nugget, we are at 9.32 and holding tight until 9.52 is out and vetted by the community. :)

2) Wait for 9.52, as the defect with MySQL 5.5 should be taken care of in that release. We don't have a concrete release date for 9.52, but I do know the hope was that it would be out sometime this week, though I obviously can't guarantee that will be the case.

@amanda.wulff: Great - thank you. That's good to know, and also thanks for a heads-up on the MySQL stuff. Lord knows I don't want to repeat the 8.73 > 9.32 issues we had. We will certainly wait for at least 9.5.2 then.
Would you recommend to keep MySQL at 5.5 or move to 5.6? I want to try and plan as well as possible for the next upgrade.

@amanda.wulff We hope you're ready for the flood (literally!) of beer that will be waiting for you at JNUC 2014. :D

@boettchs

The issue with MySQL 5.5 was completely unintended (and was filed as a defect), and we are still planning to fully support MySQL 5.5 so there shouldn't really be a reason that you'd have to upgrade to MySQL 5.6 unless it was just something you wanted to do to get your environment up to a slightly newer version.

In terms of MySQL 5.7, since we're on the topic of versions, we haven't yet fully tested that one, so I can't say I'd recommend that in a production environment just yet. We do have a few people who are testing it out in dev environments. I haven't had super good luck with it, but others have had an okay time. Still, not something for production just yet.

Amanda Wulff
JAMF Software Support

@donmontalvo

Alas, we only get day trips to the JNUC this year (and I work in the Eau Claire office as opposed to the Minneapolis office), so I'll have to leave when our shuttle leaves. :(
Not quite sure what time that is, as the shuttle/ride schedule hasn't yet been finalized.

I'm on the schedule to be there on Tuesday, Sept. 14th, though.

Amanda Wulff
JAMF Software Support

@amanda.wulff - thank you for that. If we don't need to move up, then we'll leave as-is. Your help is much appreciated.

I can report that this is happening in Yosemite (10.10)

I can report 10.9.5, and 10.10.2 with JSS 8.73 issue is occurring.