Inventory update stuck on some machines & apps not installing

[bbot]

Possibly two related issues. I have a policy that runs inventory check once daily using the Maintenance Tab, and checking "Update Inventory" On ~25 out of 600 machines, they are not performing inventory update. They are checking in, but haven't updated inventory in weeks. If I ssh into the machines and run "sudo jamf recon", it'll sync. How are you guys updating the inventory on your machines?

On the same machines, policies to install programs are not installing. I've gone into the machines and run sudo jamf policy. The policy will get stuck at Installing _.pkg. After 20-30 minutes, i hit command + c and it'll log it to Casper that it was successful but nothing installed. Also tried manually installing the pkg using "sudo installer -pkg" and it also hangs. Not sure if this is a general OS X related issue or JAMF related.

Has anyone seen this before?

[bbot]

Looking at the policy logs, the bottom two in the screenshot are the ones not executing. The top one is successful. Looks like the "update inventory" option is broken. Perhaps I can replace this option with a single line shell script that just does "jamf recon" Thoughts?

[RobertHammen]

I've got a similar problem with a couple of machines hanging up during a recon/Update Inventory. Interestingly enough, if the user logs out, the inventory updates (and any policies that have a recon/inventory update) run fine. I've disabled all Extension Attributes and the problem continues... still think it's a jamf binary bug, I have a long-standing open case on it...

[petert]

I don't know if this has any relevance in your cases, but we had the same issue of a "hung" recon process.
After some investigation and looking into the subprocesses of the recon process I found a "du" (disk usage) process, which is a report on the size of all files in a directory.
I traced it back to the checkbox of "Include home directory sizes" in the "Computer Inventory Collection" in Computer Management section of the settings on the JSS.
It means that the recon process does an du on the local home directories- the process is not hanging, but just taking an immense amount of time.
The good: after unchecking that box the recon process is very swift- 10-20 seconds per computer.
The bad: we don't get an report of the status of the home folder sizes (obviously).

[bbot]

@petert Thanks for the suggestion. I am trying to uncheck the report of the status of the home folder sizes. We don't rely on this often.

[RobertHammen]

@petert That wasn't the case in our scenario, it hangs typically after the steps below, and I've let it run over a weekend and it never completes. Even wiped and reloaded the Mac, no difference. It will recon if there is no one logged in.

Locating hardware information (Mac OS X 10.11.6)...
Gathering application usage information...

[bbot]

The strange thing is that I can ssh into those machines and run a "sudo jamf recon" and it'll actually start running under the local administrator.

[Typhoon_87]

I have a few machines that either don't update inventory and/or stop responding to pushes but self services updates work. I have a case open.

[mpermann]

@RobertHammen have a look in Activity Monitor to see if you have a process that is utilizing a high amount of CPU. I've run into this issue before and there was a process (name has PPD in it) that checks whether a printer needs an update as part of the software update process. If I kill that process the recon will complete normally. I've generally only seen this problem on computers that have one of our MFP devices setup on it. I've never been able to determine what causes the issue though.

[bradtchapman]

Whoa. I wonder if this is a coincidence. We have a bunch of Macs that stopped reporting inventory on 4/26/2017.

[bbot]

Anyone ever find a solution to this? I'm still finding machines that are not able to run policies or recon.

I have to manually ssh into these machines and run a recon to get them moving again.

[khurram]

We have been a victim of this issue for a while now, we tried jamf support in relation to resolving this issue but no consistent solution is provided so far.

[MacMaul]

This is still happening with 10.9.0-t1544463445 (started with 10.7.1), and we have a case open as well. The workaround we have found is to not use the Update Inventory checkbox in the Options:Maintenance section of a policy (which only seems to work 5% of the time). We are using the Files and Processes:Execute Command section to send a

/usr/local/bin/jamf recon

instead. Whatever the checkbox is sending seems to be broken.

[hdsreid]

Having a similar issue. Running sudo jamf recon gets these devices stuck at 'Searching Path: /Users/user/Applications/'

These devices seem to have the jamf process frozen or something. If I kill all of the running jamf processes, i can at least do a policy sync command, but I cannot find a way to get these devices to report inventory without a reboot. Only happening to a few and they fall off our radar as a result. Very frustrating

[ryan_ball]

Do you have any new scripted Extension Attributes?

What output do you get when you run sudo jamf recon -verbose

[bvanpeski]

I just ran into this issue and running recon in verbose mode like @ryan.ball suggested helped me diagnose.

I saw that the recon was hanging on a specific extension attribute, so I ran the script from that extension attribute manually and something had occurred where the app that the EA script was collecting data from wanted a license agreement approved, and that was blocking the extension attribute from running. I manually approved the license, and recon ran as expected.

Added code to the installer for that pkg to auto -accept the license agreement and should be good to go for the future.

[GabeShack]

Just saw this and found that we had logged into the admin user on this computer and started an install of printer drivers (dumb HP installer) and never clicked on the close button when it was finished. Seemed to cause all jamf recons to stop and any other policies from running until we closed this out and logged out of this user.

Gabe Shackney
Princeton Public Schools

[snovak]

I've been utilizing https://gist.github.com/talkingmoose/cd142f08c95613e5bff483fa55611b8b to collect 32-bit applications and found it hanging today (started a recon as root, and opened a second terminal, and executed 'ps' to see what processes were running). So I modified it to only look in certain folders:

MacOSPaths=$( /usr/bin/mdfind kMDItemKind==Application -onlyin /Applications -onlyin /Users -onlyin /Library )