Full application report causing server to choke

I assume your Database is backup nightly? You could create a separate instance of the Database from the backup and report on that. Leaving your primary intact. Just an off the cuff thought.

I remember a thread a while back to limit the /Applications scan to n-levels to avoid reporting all the "apps" in the subfolders of /Applications because it reports on all kinds of crap most folks don't need. I'll see if I can find that - I think that would help here so you only gather how many levels deep you need and avoid all the other stuff. Does that sound like I'm reading your problem correctly?

@pblake, that is a good thought. We have been meaning to set up a reporting JSS for a while now. Looks like we finally have a reason :)

@boettchs, I am not aware of how to limit the folder depth for inventory collection. If you figure this out, please post the details!

Thanks,

--Andy

@andyinindy, I haven't located it yet. But I laughed because when I did this search a while back, I saw this post and was bummed there was no answer on it:.https://jamfnation.jamfsoftware.com/discussion.html?id=2705
I was sure I saw one that did, so I'll keep looking. It's one of those things I forgot about until I saw your post...

So I am going to try to do an Extension Attribute to use this:

find /Applications -name "*.app" -maxdepth 2

It will do the job to report only the apps that I generally need to see and exclude the rest. You can adjust as needed to change levels. Should cut way down on search time and display mess as well as potentially helping report "choke". I'm not very experienced in the scripting realm, so someone with more chops that me could likely do it in three minutes.

hey @boettchs - In case you're looking for some alternatives for your EA, here are some I'd recommend trying out. Using standard 'nix "find" can be very slow, although probably not hugely slow if just pulling applications, but still, try using mdfind (Spotlight) instead, like this-

mdfind -onlyin /Applications/ 'kMDItemKind = "Application"'

That gives you a pretty long list of applications from the main /Applications/ folder, including the full path, so a Microsoft Office application might look something like this-

/Applications/Microsoft Office 2011/Office/Microsoft Database Utility.app

If you want to shorten the output, you can do that a few ways. For example, remove some known path strings like /Applications/ and /Applications/utilities/, like this-

mdfind -onlyin /Applications/ 'kMDItemKind = "Application"' | sed -e 's//Applications///;s/Utilities///'

Using the same example app, it would output like this instead-

Microsoft Office 2011/Office/Microsoft Database Utility.app

You could also simply tell awk to only print the last column that ends with the .app, like this-

mdfind -onlyin /Applications/ 'kMDItemKind = "Application"' | awk -F'/' '{print $NF}'

This removes all the path stuff not matter how many levels deep its buried and leaves you only with the application names. Example:

Microsoft Database Utility.app

Overall, mdfind will give you more results than just the regular find function you have because unfortunately mdfind has no way to limit its search to only 2 levels as an example. it will burrow down as many levels as it can to find all applications.
There is one alternative though. You can build a bash array for lines that only contain a certain value of path slashes, simulating going only 2 levels deep for example, and output that as your result. Like so:

#!/bin/bash

while read line; do
    if [[ $(echo "$line" | tr -cd  "/" | wc -c | sed 's/^ *//') -lt 4 ]]; then
        appList+=( "${line}
" )
    fi
done < <(mdfind -onlyin /Applications/ 'kMDItemKind = "Application"')

echo "<result>$(echo -e "${appList[@]}")</result>"

The advantage to mdfind is its very fast in comparison to find because its searching a db instead of doing a live disk search.

I also just wanted to comment that we also have major issues with our JSS when doing application searches and can sometimes cause our JSS to destabilize. We've been working on this off and on with our TAM and it seems its related to bad database records that need to be cleaned up or they foul up the search.

Hope that helps.

@mm2270, I absorb everything I can learn from you guys - I'm a "Mac Guy" trying to expand and learn scripting and I'm just really a nOOb there. You can't offer up enough help for me and it's what makes this place so awesome. Never do I find myself feeling anything other than gratitude when I get helpful replies like yours! Very much appreciated. I will look at your info and see if I can make use of it. A multitude of thanks from me to you sir!