Recon running very slow on mac os x

I have a computer here that is doing the same thing and we have been scratching our heads a lot on this one. We have tried re-installing the last OS X combo update and tried reinstalling the jamf software on the machine. You're not alone on this issue!

You can add them manually (see p. 194 in the Casper Suite Administrators Guide) but I think that's just going to create a bare-bones record; you'll still have to run Recon eventually.

The real question is why is it taking so long? Recon collects a LOT of information...if you have a machine that has a lot installed already, it could take awhile. Still, 20 minutes does seem extreme.

Are there any other processes eating up resources, which would slow the Recon process down? I just recently ran into a situation with a copy protection driver than decided to go rogue & practically buried the machine, until I managed to remove the files responsible.

Also: do you have additional search paths defined other than the defaults?

Assuming Kumar and I have the same issue, the recon takes long while it is collecting information about applications. If you run a recon -verbose, you can watch it take FOREVER on each application. We are seeing this on a machine with an i7, 8GB of RAM, and an SSD, so we know it isn't the computer. No other processes are eating up resources, just the jamf process.

I don't want to hijack the thread Kumar, but I'm hoping our issue is caused by the same thing and we can both get it fixed!

Another thought: does it happen on machines that are already enrolled? If you let one of these machines finish, then open Terminal & run Recon manually:

#>  sudo jamf recon

Is it still slow?

EDIT: Ok, I see that it is. Hmm...

@Chris, I do you have additional search paths defined other than the defaults.

I have 600 machine that need to be redirected and for a simple recon process it is taking 20 min minimum and imagine the time taken by my engineer's to redirect machines, they feed up of this process, they are asking me any alternatives.

@Jason, I am very much sure that there is no other process that is running, I have sys configuration of i7+4GB DDR3 RAM, I do not thing so that to run recon machine require 8GB of RAM.

@Anil: I think you misread what I said. I was saying that we are seeing the same behavior on a machine with that configuration. I know a recon shouldn't require 8GB of RAM :-)

If you run jamf recon -verbose, is there anywhere in particular that it slows down or is it just overall? The reason I asked about the paths was just in case it started going down a rabbit hole...I have a single additional path defined to search for my custom apps, but it's a very specific directory that I created, so it's not traversing any links or anything.

I just ran it on a computer here (my Diagnostic server, an older Mac Pro running 10.6.8 Server) and it finished in less than a minute, so I'm not sure what else to say, sorry. If it's a recon bug causing the problem, though, then that is something in JAMF Software's realm.

In your Inventory Collection Prefs, start disabling things one at a time and re-running Recon on a single test machine in between edits.

Are you collecting Plug-ins/Unix Executables (doubt that's necessary, takes a while, and hogs up DB space.)
What about are you Collecting Available Software Updates? In my environment we have an authenticated internet proxy, if the machine has been idle for a long while and is requiring a new proxy auth., it hangs there for a long time during recon.

In my case, it would take the longest just scanning applications with no extra search paths specified.

That was happening to me on a few machines. The verbose log was a little misleading. Locating Applications was the next step on the list, but we were really stuck calculating home directory sizes. In my JSS I went to Settings, Inventory Options, Inventory Collection Preferences, Accounts and unchecked the box for Calculate Home Directory Sizes.

@Daniel Calculate Home Directory Sizes has already been unchecked.

Have you contacted Support yet?

Collecting font info also slows things down, and inflates the casper DB.

I also came across this on one of my test machines.

And only later thought… Humm perhaps if I had unmounted my external disk stack, and ejected the other disk partitions first…
That would have helped considerably…

Similarly if someone has an external HD attached, especially if there is some issue with it
– that can really slow things down.

Many of you have posted, but I haven't seen some other important details to help piece this together. I'm running into a similar issue. Recon is taking a long time as the subject suggests, several minutes, upwards of 10-15. If you're watching the command line it is hanging up on Locating Applications, much longer than I ever recall it taking. I pretty much collect next to nothing beyond the basics: Basic Application information (name and version from the default path), Package Receipts, Available Software Updates, All the Account Info, and Extension Attributes.

What I wanted to see from more people was their JSS version and the OS versions they've had this happen on. I'm on 8.62 and this far have really only noticed this on 10.8.2. A 10.6.8 box zips on through quickly, as does a 10.7.5 box. I noticed that a coreservicesd process was working hard at the time.

I haven't gone to support quite yet since I have bigger fish to fry before next week.

I'm noticing the same with 10.8.2. 10.7 runs smoothly, but 10.8 is hanging on locating applications for 5 to 7 minutes. Using verbose I'm see it hangs on several Microsoft Office 2011 applications. For me this happens both on first time enrollment and subsequent recon submissions. I opened a support case just today on this.

The plot thickens. I have three machines now that are running all the same stuff as the ones beside it, but recon blazingly fast. 10.8.2. Now to figure out why...

@ ernstcs, exactly the same here. 10.8.2 SLOW.....10.7 speedy.

One of my cohorts tracked it down to old Apps from a previous package. Specifically iLife '11 package, iPhoto 9-1 Update package, which also in turn stopped App Store from updating.

Hello has anyone found a solution to this? i've started getting complains from some of my users that the jamf process is taking up to 3.5GB on memory resource and slowing down things on their device.. I pretty much have disabled almost all inventory preferences, next thing would be the plugs in, but it has not made a difference with everything else.

Have you tried exporting a System Profiler from the machine (a full report, not the 'less'). Try running it via the command line and see if it takes a long time to go through the full report.

system_profiler -detailLevel full

While a system profile isn't everything that is in the recon (EA's, home folder size, etc), if the System Profiler can do a full report in relatively short amount of time I think you can narrow this down to more of a recon/JAMF issue than an OS issue. If the system profile takes forever though, then you're talking an issue with the OS not a JAMF issue.

But that's just a hunch...

Are you collecting plug-ins? If you have that enabled, it will search the /Applications directory (even though it isn't explicitly specified) for plug-ins. Adobe apps and IDE's will cause a very large number of plug-ins to be registered.

Check that setting, and look at the size of that table. When I had this enabled, I had 10's of thousands of plug-ins in the database because of Illustrator and Eclipse.