+12We have an agent that runs on startup that checks for packages in the Waiting Room. If any are found a "jamf installAllCached" is executed followed by a recon and then a restart. For whatever reason, I've got a package (Firefox) that is installed but isn't being deleted. Because of how our agent is written this then causes a reboot loop.
Has anyone seen this situation where a cached packaged is installed but the package and xml file aren't being deleted afterward?
+15If you're going so far as your own agent, why not just run the installers directly and delete when done? Why even call JAMF to do it? And you might want to reconsider that reboot. It shouldn't be required except for a few Apple updates. And you can just run softwareupdate -l |grep restart to see if one is required...
EDIT: And no, I haven't see the cached package not be deleted. I suppose the JSS thinks the install failed...? Anything in your firefox install logs?
+12@thoule Thanks for the reply. Great ideas but we're on a locked down network and running "softwareupdate -l" isn't going to be able to reach Apple.
What's curious is that this solution has been working for over a year and has served us well. There are some updates we'd like to do, but in general it's solid. Having it restart allows us to keep it generic and support any kind of updates. Hardest part has been training users to restart frequently.
Running "jamf installAllCached" manually on the a workstation with the package cached exhibits the same behavior; the package is installed but the pkg and xml files aren't deleted as they should be. Watching /var/log/jamf.log doesn't indicate any error. In fact, running "jamf installAllCached -verbose" even indicates "verbose: Removing local copy..." but it doesn't actually do so.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
