Skip to main content
Question

Stuck Policies going nowhere

  • March 18, 2010
  • 2 replies
  • 32 views

Howdy all,

I have a policy called Force Recon {All Computers > Once per > triggered by every 5 mins (Scheduled task I made randomize by 1 minute runs as Root)}
All this policy does is Update Inventory (Recon)
I made this policy 24 hrs ago and been running all night.

I know some machines are shut off and/or Out of Office so this doesn’t apply.

However I do have machines that I know are constantly running (OS X Servers w/ static IP & one Ethernet) as an example but not limited to)
I can ssh remotely from my Terminal.. I can run jamf recon at the CLI and reports back to the JSS.. ARD works... I can push packages with Remote without errors.

For example: I have one OS X server 10.5.8 with the latest and greatest updates physically next to me.
One policy (a package install) ran successfully however 10 days after I made the policy. The policy I made yesterday (see above) is still waiting to run on this Server.

So I don’t get what is happening not can find a common denominator. But I can say this has been with me since our inception of Casper 6.01.

Anyone else with this?
Casper Server is MacMini 10.6.2 Server running JSS 7.1
Clients are mixed and matched machines 10.5 to 10.6 all with JAMF 7.1

Thanks in advance!!!

-P@

--
Pat Camporeale
The Mac Dude
180 Amsterdam
Herengracht 506
1017CB Amsterdam
+31 20 422 2180

Web 3.0 will provide downloadable buttered popcorn .. Don’t be daft, of course it’s edible!!

DISCLAIMER 3/18/2010

This communication is intended only for use by casper at list.jamfsoftware.com. It may contain confidential or privileged information. If you receive this communication unintentionally, please inform us immediately. Thank you. 180 has registered companies in the United States and in the Netherlands. 180 Los Angeles LLC . (180) 1424 Second Street, Suite 200 and 300, Santa Monica, California 90401, is registered with the trade register in the US in Delaware under file number 4260284 and the corporation's FEIN is 20-5982098. 180 Amsterdam BV (180) Herengracht 506, 1017 CB, Amsterdam is registered with the trade register in the Netherlands under number 34253037 and VAT number NL8161.54.673.B.01. The content of this communications is not legally binding unless confirmed by letter or telefax. Please note that 180 is neither liable for the proper transmission nor for the complete transmission of the information contained in this communication or for any delay in its receipt. Also please note that the confidentiality of email communication is not warranted. All services and other work provided by 180 are subject to our general conditions (supplier terms and conditions). The conditions are available for inspection at Herengracht 506, Amsterdam and at the Chamber of Commerce in Amsterdam. If you wish to receive a hard copy of these conditions, please send an e-mail with your address to info at 180amsterdam.com <mailto:info at 180amsterdam.com>

In the event you send to 180 any unsolicited ideas and/or materials (whether consisting of texts, images, sounds, software, information or otherwise) ("Materials") by e-mail or otherwise, 180 shall be entitled to use, copy and/or commercially exploit such Materials to the fullest extent, free of charge and 180 will not be bound by any confidentiality obligation in respect thereof.

2 replies

RobertHammen
Forum|alt.badge.img+29
  • Esteemed Contributor
  • March 18, 2010

What happens if you do a "sudo jamf manage"? This should create the every5 task in /System/Library/LaunchDaemons, if it doesn't already exist there, as well as the usage monitoring task, if you have that enabled. I've seen OS upgrades/reinstalls nuke these, so you have machines which work fine for Self Service but do not check in with the JSS.
On Mar 18, 2010, at 7:34 AM, Pat Camporeale wrote:

if you do "ps aux | grep jamf" <-do you see a jamf process running/stuck? If so, try sudo killall jamf, then jamf recon and see if it completes.

Also useful is the jamf.log - as in, "tail /var/log/jamf.log" <-do you see the task running there?

Hope this helps,

--Robert


Forum|alt.badge.img+5
  • Contributor
  • March 19, 2010

I find a lot of times, since almost all my users are mobile, that the jamf
process will get stuck on a policy and not run any of my polices that I have
set. Inevitably, most of them show up in my smart group that I have created
to alert me if a computer hasn't checked in to the JSS in over 7 days. What
I do then is either email the user and have them restart or using ARD, I
have a unix command saved that does the following...

killall jamf
killall jamf
jamf policy -trigger every15

You will notice that I have put in the killall jamf twice, this is almost
always the case in my environment that there are two instances of the jamf
binary running or the first killall doesn't do the trick.

Every once in a while I will open up ARD, select all, and run a jamf recon
for safe measure. Not really sure, how useful this is, but it is just one of
those things that I do to check that everyones' jamf binary is behaving.

--
Alan Benedict
?
Macintosh Technician
The Integer Group
O: 515-247-2738
C: 515-770-8234
http://www.integer.com