Inventory taking forever on one Mac

[AVmcclint]

I have a Mac that has suddenly begun to have problems. When I run "jamf recon" or have an inventory run after a policy install, it doesn't seem to finish. I let it run once for 45 minutes and it never got past "Gathering application usage information" I have rebooted many times, I have done removeMdmProfile and mdm with no change in behavior. I've purged user caches... I can't figure out why this mac has begun doing this and it is causing problems because it can't do any other jamf tasks like check in to the server while it is stuck like this.

Other than reimaging the whole computer, what can I look for?

[stevewood]

@AVmcclint have you tried the verbose flag to see what the recon is hanging up on?

jamf recon -verbose

[tlarkin]

you can also save a copy of the recon locally to see the output of the XML it is trying to POST to the JSS.

sudo jamf recon -verbose -saveformto /path/to/local_copy.xml

Sometimes there might be weird apps it has problems parsing. I have seen this once or twice with old versions of the MAMP stack apps.

[AVmcclint]

Thanks! I totally forgot about -verbose. By the time I was able to read your response the computer finally finished an inventory. I'll check it again today when the computer comes online.

[AVmcclint]

It seems like the problem has resurfaced. This time I ran jamf recon -verbose and it hangs at "Gathering application usage information..."

[...]
verbose: Running script for the extension attribute McAfee - Update Status
 verbose: Running script for the extension attribute McAfee - Virus Definition Date
 verbose: Running script for the extension attribute McAfee - Virus Definition Version
 verbose: Running script for the extension attribute SMART status
 verbose: Running script for the extension attribute Uptime
 verbose: Finding CoreStorage information...
 verbose: found CoreStorage PV disk0s2 LVG UUID: E1C5F5BD-CC84-4FE2-B764-3C61E702E4CF
 verbose: found CoreStorage LV disk1 LVG UUID: E1C5F5BD-CC84-4FE2-B764-3C61E702E4CF
Locating hardware information (Mac OS X 10.11.6)...
 verbose: Device is BLE capable: no
 verbose: Checking AD status...
Gathering application usage information...
 verbose: Looking in 2017-01-30
 verbose: Reading (null).plist...
 verbose: Reading admin.plist...
 verbose: Looking in 2017-02-15
 verbose: Reading (null).plist...
 verbose: Reading admin.plist...

And that's it. 45 minutes later and it's still stuck on that. This particular Mac only has a single admin user and no other accounts. I checked /Library/Application Support/JAMF/Usage/ and the files in there look normal to me. This computer doesn't get a whole lot of use so the .plist files were very short - as you might expect. I still can't figure out why any computer would hang at that step in the inventory.

[jhbush]

@tlarkin I think that is what I'm seeing on a machine that has multiple versions of the MAMP stack installed in the /Applications folder

[tlarkin]

@jhbush1973 that was a few years ago but at the time we did find that if we removed the MAMP stack from /Applications recon did not hang. I am not sure what the customer did to fix it beyond that. Some MAMP copies would not do this, so we were unsure if this was an environmental issues or a jamf issue.

EDIT - I know this was at least 2 years ago not sure why the date stamps on this post do not reflect that?

[Adminham]

Old thread I know.. But stumbled across it as I'm having the same issue with recon taking forever/not finishing at all.
What I've found is that it's failing on computers that I've performed an eraseinstall on (10.14.2) & haven't yet logged in since the re-install.
The first login looks like this:

After this first login, recon works fine! My assumption is that something is busy/locked until this post install process takes place.
Any other theories or additional info about this update process would be appreciated.

[jlang_remedy]

@Adminham having this same issue. Were you able to get around it?

[Adminham]

@jlang_remedy Not really, tho I noticed that pushing the recon command from the Jamf Recon app seems to work more reliably than the equivalent UNIX command from ARD..

[allanp81]

We saw this issue and it was due to us mounting their home drives via AD and it was trying to calculate the contents of this.

[Adminham]

@allanp81 It may pay to check any custom Extension Attributes that could be 'running rouge rogue'. I've been caught by that before..

[allanp81]

Rouge or Rogue :)

[Adminham]

@allanp81 it was a bit of a powder keg, & caused some blushing, so..

[szultzie]

Hi All,

I am seeing this trying to use a recon thru ARD when there is no user logged in. I also don't remember this issue on 10.13.6.

Just on 10.14.5 or 10.14.6 machines.

-Peter

[eric_mead]

Hey, me too! Exact same issue as Peter. jamf recon works fine from ARD when you're logged in, and fine when you type it directly into terminal, but has ceased working when there's no user logged in, even with root privileges. Anybody else notice this/have a workaround?

[szultzie]

So I am working with Jamf support, they are thinking its one of the extention attributes and are trying to narrow it down.

[eric_mead]

Thanks so much for the info, please do let me know if they get back to you with a resolution. I use recon through ARD all the time - super annoying not to be able to do it to a whole classroom at once =)

[kmathern]

~[upload](ff52de5ee9c24e8fa96548dc6a24837f
the two pc's I've tried it on today are hanging at the user name.plist
all me EA's are after that .plist so it could be the EA's that I'm using. But all my recons are taking a long time on all my systems.

[szultzie]

So nothing yet from Support. But we did upgrade to 10.15.1 last night, so this morning i disabled all EA and still seeingthe same issue, so its not the EA that i had at least.

[groiss]

i found this way useful when debugging a stuck recon:

open a terminal session running

sudo jamf recon -verbose

when recon starts to get stuck, open a second terminal session

sudo ls -alnt /Library/Application Support/JAMF/tmp

in there are the cached scripts - the tmp files are named after some UUID or so. So you can just cat in the newest created file in the folder (if there are more) and view the code of the stucked script.

sudo cat /Library/Application Support/JAMF/tmp/{UUID} (eg.D78B1400-5F01-4744-AF71-4B8A2A76C585)

[AquibS]

@groiss Great its worked for me Thanks!

[NateES]

I've been having Recon take more than a few minutes on my machine (13" MBP 2017).

@groiss's suggestion didn't show anything, but if I used Activity Monitor's Sample, I find a lot of CPU usage spent on threads for 'ReconCommmand getAppInfoAtPath'.

Does Jamf walk the entire directory tree of scoped folders and try to find any .app package within? Would it not be more CPU efficient to pipe the output of 'system_profiler SPApplicationsDataType' and return all apps within scoped folders, or is there some inherent security risk in doing this, where a less efficient process is preferable?

[NateES]

A detailed update to my recon investigation:

Running:

sudo jamf recon -verbose

Shows progressive output of app paths during the entire command, walking the /Users/ directory taking the longest amount of time, walking /Applications/ taking the shortest amount of time (but strangely enough run at the end).

To decrease the amount of time spent in recon, we're currently looking at excluding paths from running apps, such as in this thread (and thus being able to exclude them from recon app path walks), but during the long process of debugging this, I've realised that I'm just constructing a workaround for an inefficiency of the recon process.

So, to analyse what recon appears to read from the Mac, I ended up looking into the JAMF API reference.

The API reference shows the following information recorded for an app:

 "applications": [
    {
      "name": "Microsoft Word",
      "path": "/usr/local/app",
      "version": "1.0.0",
      "macAppStore": true,
      "sizeMegabytes": 25,
      "bundleId": "1",
      "updateAvailable": false,
      "externalVersionId": "1"
    }
]

Using information from a live computer:

    {
      "name": "Automator.app",
      "path": "/System/Applications/Automator.app",
      "version": "2.10",
      "macAppStore": false,
      "sizeMegabytes": 6,
      "bundleId": "com.apple.Automator",
      "updateAvailable": false,
      "externalVersionId": "0"
    },
    {
      "name": "Microsoft Outlook.app",
      "path": "/Applications/Microsoft Outlook.app",
      "version": "16.43.20110804",
      "macAppStore": true,
      "sizeMegabytes": 1636,
      "bundleId": "com.microsoft.Outlook",
      "updateAvailable": false,
      "externalVersionId": "0"
    }
]

I don't know about anyone else, but I can only see the following data being used within the JAMF GUI:
In Computer Inventory -> Applications, the following 4 columns:
• Name | • Version | • Path | • App Store
In Computers -> Smart Computer Group Criteria, the following 3 criteria:
• Application Bundle ID
• Application Title (Name)
• Application Version

Fields not in use as shown by the API nor the GUI:
• sizeMegabytes
• updateAvailable
• externalVersionID

Now, comparing against running

system_profiler SPApplicationsDataType

Time taken: seconds for the full output to appear.
Example output:

    Automator:

      Version: 2.10
      Obtained from: Apple
      Last Modified: 1/1/20, 7:00 pm
      Kind: Universal
      Signed by: Software Signing, Apple Code Signing Certification Authority, Apple Root CA
      Location: /System/Applications/Automator.app

   Microsoft Outlook:

      Version: 16.43
      Obtained from: Mac App Store
      Last Modified: 17/11/20, 9:19 am
      Kind: Intel
      Signed by: Apple Mac OS Application Signing, Apple Worldwide Developer Relations Certification Authority, Apple Root CA
      Location: /Applications/Microsoft Outlook.app

Fields available:
✅ Name (Title?)
✅ Version
✅ App Store (Apple/Unknown/Identified Developer/Mac App Store)
❌ Last Modified
❌ Kind
❌ Signed By
✅ Location (Path)

Missing: 🤔 Bundle ID.

Unfortunately I'm not sure how to get the Bundle ID from the output without running:

mdls -name kMDItemCFBundleIdentifier "/Full/App Path.app"

for each app location, but I'm sure that output can be created at a much higher speed than waiting for recon to walk the app paths and individually interrogate each app for the all the data fields listed.

It's possible that the recon speed could be improved, and I hope quite significantly.