@aamjohns: I see that one too using Win 2008 R2 and SMB DP's. I always figured that this error was caused by an install of a newer version of an existing app that was "open". So if I have Word 14.3.9 open on a Mac and try to install 14.4.2, it will fail with that error. At least that's what I thought was the cause - could be totally off on that...
A lot of our install pkgs are served up only for techs to use during imaging, and normally they don't encounter open iterations. Might have to start adding scripts to kill the apps to see if that helps.

@aamjohns Interesting, I'll try using a script to run recon instead of the checkbox to see if that helps.

I also see the "Installation failed" when installing a flat pkg over HTTP (actually a JDS), but MUCH less frequently than I see the timeouts. The install failed error comes up maybe once a month, whereas the timeouts happen at a rate of about a dozen or so a week.

@boettchs][/url,
Good point. And I have started to investigate that. I have not yet determined that is the issue for certain, but it very well may be the case. I will be sure to keep that in mind and continue my investigation to see if that is indeed the issue.

I recently implemented a script that will not try to install certain updates if the application is open. In this case Adobe Acrobat Pro and Office 2011. I could force close the applications first, but I do not want to do that to our users. So the policy will try to run and if the apps are open, it reports that back and does not attempt the install. I also have this updates set to run at login which should help with the issue, but so many of these people go huge amounts of time without logoff logons.

@wyip,
I hope it works for you. It works very well for me.

@aamjohns: that's the worst part about "pushing" apps as opposed to using Self Service. Some people have 20 apps in the "login items"; some never logout/reboot, so certain hooks are useless too. You can't just nuke an app while they're using it so it's a balance of force and skills on our end. I don't have the advanced skills yet to do some things that would be nice - like telling a user that we need to upgrade X, Y, and Z so please quit them. Working on it, but there are sometimes no simple answers to what seem like simple problems.
If we could rely on users to go into Self Service and download items, it would make a lot of this easier.

@boettchs,
Yes, I have all of this setup in self service, and if they went there and clicked on the item, it would tell them to close the applications first. And this method would probably work fine. But they are not doing it like I had hoped.

I agree about notifying people that there are things they need to do because we have updates that need to be installed. And I have been exploring the idea, like you mentioned, of coming up with a way to let people know this through some sort of dialog coming up. I intend to pursue that. Here lately I've been bogged down with other things I have to do but yes, I agree with you, notifying people that there are things that need to be installed, and how to do it.

Strangely, while I get this error still, it doesn't seem to be causing any problems. Policies work, self service works.
Does anyone have something that ISN'T working because of this error?

We don't seem to be having any issues with it either. It seem like it is just a minor annoyance.

Not to revive a somewhat old thread but does anyone know if this has an actual defect number?

I am seeing the same thing under a Windows 2008 R2 JSS running 9.31 and was going to open a ticket under the defect number.

It's more of an annoyance for the MacAdmins who get the email alerts than anything else as far as I can tell everything is still working as expected.

Has anyone been able to solve this? It's been driving me crazy lately.

My solution is to run a shell script that runs recon and not use 'update inventory'.

We see this many multiple times a day and then once I started ssh'ing in and running it on machines that were seeing this a lot it was always taking forever at gathering the application usage data / not getting past it at all. We don't really use this data anyways so we don't need it.

I turned off collecting it and I haven't seen the issue once since.

From a purely manual recon-perspective (not re: policy, etc)...
I see all OS X clients throwing errors every time—though JSS appears to get updated info from clients, so this may just be binary status bug; not a functional bug.

The errors occur at the end of recon, when "Submitting data to http://myjssfqdn:8443/..."

The error is slightly different over Wi-Fi-only (802.1X, fyi)...
"There was an error.
Connection failure: "The network connection was lost."

Compare to error over LAN (w/ or w/out Wi-Fi)...
"There was an error.
Message has no content."

JSS v9.5.2 (Test) running clustered on OS X 10.8.5 and behind HAProxy (fairly "stock" config).
FYI: checkJSSConnection always reports "The JSS is available."

JSS 9.52
Windows 2008 Server R2

I am seeing this problem as well, mostly with recon. The problem occurs when "Gathering application usage information." While I am thinking that the "shell script (jamf recon) rather than update inventory" solution is best, I would also recommend that you look at the size of the application table size (JSS > JSS Information > JSS Summary > check all the buttons > Create, and look for table sizes) just in case the table size is too large.

I am seeing this on JSS 9.63, AFP distribution points. One thing I am noticing is that it appears to be happening on machines connected via Remote Access, I can tell because the IP addresses being reported are not corporate network, they are the ISP.

Thanks

I'll jump in on the fun. I see this form time to time but have attributed it to laptops being disconnected or put to sleep before being able to submit the report. I can't promise it but it's fairly minor in occurrence here:

9.63
AFP

I keep getting: Error running recon: Connection failure: "The Internet connection appears to be offline." or Error running recon: Connection failure: "The network connection was lost."

This is happening after a script runs.

JSS 9.63

I am also seeing these issues.

Error running recon: Connection failure: "The host xxx.xxx.xxx.xxx is not accessible."
and/or..
Error running recon: Device Signature Error - A valid device signature is required to perform the action.
and/or..
Error running recon: Connection failure: "The request timed out."

Has there been any movement on this. I don't want to have to add a script to run recon?

Master = 10.9.5 / server 3.2.2 / JSS 9.6.2 mysql 5.6

Does upgrading to 9.65 fix this issue?

Same here. And my JSS is fully up. And no 9.65 does not fix this issue.
I'm starting to wonder if it's the number of connections that tomcat or the database (is getting from tomcat) that is creating this error? Not accessible because it doesn't answer in a timely fashion?

i was thinking the same thing about to open the jus database and check the tomcat settings.

nope I'm at 151 allowed connections.

What is the frequency of these with everyone. In a daily inventory report I'll get say, 600 successful inventory reports and about 20ish failures. Those failures are generally a mix of:

Error running recon: Connection failure: "The host xxx.xxx.xxx.xxx is not accessible."
and/or..

In which I am able to verify that those units are connecting through a non local network (whether it's a hotspot, or home Wifi).

The rest are those

"Error running recon: Connection failure: "The request timed out."

...which given the small numbers I'm seeing, I assume my laptop wielding user closed the laptop or otherwise disconnected form the network. I am NOT seeing the device signature errors. That said I am running MySQL 5.5 because of early issues we had with 5.6. This was about 2 years ago and I never felt the need to get back up there.

Is there a recommendations table for MySQL connections? I have one for Tomcat, but not MySQL...after 9.65, ours was set to minimum and I bumped it up a little as I thought we had done so previously.

I'm not sure about a table. I set Max threads in ROOT/WEB-INF/xml/DataBase.xml to 400 (401 in MySQL, that last one is for MySQL itself) and then 2.5 times that number for Max Connections in /Tomcat/conf/server.xm. So 1002 in my case.

So, this is happening on desktops as well as laptops, so I don't think it's a sleep issue.