I'm seeing this as well, more so with 9.22
Or I get, "Executing Policy Update Inventory...
Running Recon...
Error running recon: Connection failure: "The request timed out."
FWIW- we often see these responses when machines do not have proxy settings turned on because we have a proxy in place.
What do you get when you try to check the connection to the jss on that machine?
Or if you try to run a manual recon?
or load https://xxx.xxx.org:8443 in a webpage?
sudo jamf checkJSSConnection
sudo jamf recon
I keep seeing this quite a lot since going to 9.21 and also in 9.22..
I also started seeing quite a lot of errors with clients failing to connect to http distribution points and failing over to afp, which works ok. I don't yet know if this is related though..
Related to https://jamfnation.jamfsoftware.com/discussion.html?id=9041 ?
/Peo
Error message is: Error running recon: Connection failure: "The request timed out."
I also tested a manual recon by ssh-ing in and running "sudo jamf recon -verbose" on a workstation that failed to run a recon after a policy. And it recon perfectly fine.
I wonder if this is a bug....
Are people experiencing this issue anymore with the updated version of the JSS namely 9.3 and 9.31?
I too am seeing this very often. Almost daily on what seems to be random computers.
I am seeing the Error running recon: Connection failure on random clients.
We are on JSS 9.3.
Manually running a recon works fine.
I would like to add I am seeing this more and more (currently I am on 9.31).
Connection failure: "The host <our host name>.xxx.xx.xxx is not accessible."
It just happened this morning to me with my computer. Right after I saw it in the log I ran
jamf checkJSSConnection
and that came back ok. I manually ran recon and that worked.
Also, I have a lot of systems that will not run recon as specified in policies. For example, run a software update package and then update inventory is check. The software installs, but no recon. It has become so prevalent that I have un-checked that option in the policy and I use an 'after' script to run recon.
Finally, I am getting this a lot now:
Installation failed. The installer reported: installer: Package name is <package name> installer: Upgrading at base path / installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
It may work on one computer and not another.
I wish I had a way to diagnose what is going on with all of these issues.
Just to chime in. I am also seeing this daily on "random" computers. I'm wondering if the network connection is dropping during recon or maybe the user is unplugging their network cable. I'm not sure, but it's still happening often.
using version 9.3
I'm seeing the same thing here. On April 10th we upgraded from 8.73 to 9.3 and I started seeing this problem. We've since moved to 9.31 and the problem persists. I've seen this issue with kiosk computers that are connected with ethernet to our network and set to never sleep. I've had other bigger problems with the upgrade to 9.3 that I haven't spent much time trying to figure out what is causing this one.
Add me to the list whom are seeing this more since 9.3.
Haven't moved to 9.3.1 yet nor have I logged it or looked into it.
Anyone opened a ticket with support?
I have a number of test machines, some of which are exhibiting these symptoms, and they are awake and connected via Ethernet. Only some do this, and not necessarily all the time, I may get failures and then later the policy works.
I am also seeing this, post 9.3 upgrade. I opened a ticket with support, but the problem is random enough that they couldn't isolate a source. I'm hoping that 9.31 will help.
I also have logged a support ticket with JAMF as well and due to the nature of the problem being so randmon. We were not able to replicate it.
We did look at the system log file at the time of the occurance and did note the error message which is
May 12 02:56:58 XXXXXX kernel[0]: AFP_VFS afpfs_unmount: /Volumes/CasperShare, flags 0, pid 7486
May 12 02:56:58 XXXXXX kernel[0]: ASP_TCP Disconnect: triggering reconnect by bumping reconnTrigger from curr value 0 on so 0xffffff8013d8eb80
May 12 02:56:58 XXXXXX kernel[0]: ASP_TCP Detach: Reply queue not empty?
After googling it seems that this problem is not isolate to just OS X 10.9 (which we're using here) but this also occurs in previous version of OS X. And I do recall reading that it could be due to Apple phasing out AFP in favour of another protocol.....
Ours are http distribution points...
Are we all seeing this when deploying non-flat pkg's?
I'm seeing this issue as well (policy executes fine except for recon submission). Running JSS 9.3.
I'm on 9.31 and am seeing this too, both when a policy installs a package or with the policy that just runs the daily recon. I've also seen this when installing a flat pkg built with Composer.
I opened a ticket with support and we looked at my load balancer first (we're using pound). We tweaked some settings there, but I'm still seeing about a dozen timeouts a day (out of 2k+ managed systems). If I ssh to a system and manually run a policy or a recon, it works fine.
Goodness, so glad I found this post. I thought something was going wrong w my server. I'm having the same issues. Something else I'm curious about is what server everyone is using? I saw some mentions of 10.9 server having connectivity problems, but I upgraded to 10.9(.3) at the same time I upgraded to Casper 9.31, so not sure if that's related...
@khoppenworth, we also upgraded our OS to Mac OS 10.9.x when we upgraded our JSS to 9.31. We were originally on Mac OS 10.7.5 and JSS 8.73 and didn't experience these issues. Is everyone that posted here using a version of Mac OS to host their JSS?
10.9.3 server and 9.31 for the JSS for me. Still seeing this daily.
We are also seeing this issue on a 9.3 JSS running Windows Server 2008 R2 with an HTTPs File Distribution Point utilizing separate 10 Gb NICs for the JSS traffic and HTTPs Distribution traffic.
This is a very random issue as well for us but it seems to rear its head more when we do a mass policy deployment of a piece of software.
Our OS X 10.9.x AFP Distribution Points appear to return better results when sending in their recon results back to the JSS. We believe this could be a network traffic capacity difference between our AFP Distribution Points and our Primary HTTPs Distribution Point since our Primary Distribution Point has a 10Gb NIC but our AFP Distribution Points have only 1Gb NICs. In theory our 1Gb Distribution Points would distribute software more slowly than our 10Gb Distribution Point which would then cause the recon process on each client that is waiting to download the software prior to doing its recon process to space out the Recon data being sent to our JSS causing less errors when talking to the JSS.
Two thoughts my team has on this issue:
1. We are reaching a thread count limit when systems are reporting recon data to the JSS during mass deployments when we are utilizing our 10Gb Distribution Point
2. There is a bug in the JAMF binary on the client where it drops the connection for some reason while trying to send recon data to the JSS during a policy deployment
I'm seeing this on Windows Server 2008 R2, but was thinking about migrating to Linux since our data center team just announced that they now support CentOS/RHEL/Ubuntu. I figured it was an idiosyncracy of trying to run Tomcat & MySQL on Windows.
i see this too, a lot. even on 9.32.
I'm on Windows Server 2008 R2 now running 9.32. Distribution is over HTTP. Now that I have quit using the 'update inventory' checkbox for recon and use an after script that runs recon, I am getting my inventories fine.
I still have to deal with this issue (no workaround for this one):
Installation failed. The installer reported: installer: Package name is <package name> installer: Upgrading at base path / installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
