+1 on this: We're having exactly the same problem. Same error, same environment. However, we're running Jenkins 2.101, but we had the same problem when running Jenkins 2.97.

This is a major problem for us, since most of our longer Jenkins builds fail due to a connection timeout.

Form which version have you upgraded BTW?
And which Remoting version are you using on agents?

We are running version 3.15 on both our Windows slaves. However, only one of them seem to be behaving this way. While there are some differences between them, I am not really sure what would be relevant. If it is of interest, perhaps it is possible to dump system properties in some way?

I am not sure what version we were running before 2.97, but I would guess on Jenkins v. 2.92 based on when we updated.

In hopes of increasing visibility on this issue, I would like to share that I too have agents close connection for various reasons, sometimes unknown and sometimes known. The unknown reasons I have no information on other than these agents run on MS Windows of various versions or run in Kubernetes using the official docker image on stable Kubernetes hosts.

The known reasons have to do with running agents again in Kubernetes with the same image but on preemptable hosts (hosts that can be taken down by the cloud platform whenever it needs space). Thus the agent is shutdown in the middle of an operation which cause the channel to close.

My concern in this JIRA is the unknown reasons for channel close and no information in logs.

We are using Jenkins Master 2.107.3 & agents using jenkins/jnlp-slave:3.19-1 but also occurred on older versions of both.

I can mention that we are not having these problems anymore! I think in our case, our problems were solved by something so simple as fiddling with the Windows sleep/hibernate options...

We are also facing same error. we are using 2.107.1 jenkins version. We have many builds running on this slave. Good thing is it is getting connected automatically after 15 mins. But it is creating much problem

Several of these issues involve similar reports but possibly very different causes. Frequently the error indicates that the channel is closed but provides no indication as to how or why that occurred. Commonly remoting issues involve something in the networking or system environment terminating the connection from outside the process. The trick can be to determine what is doing that. In one instance (JENKINS-52922), Nush Ahmd discovered that setting hudson.slaves.ChannelPinger.pingIntervalSeconds kept the channel from getting disconnected. Or as sfabian noted, fiddling with Windows sleep / hibernate options. Or various timeouts.

One thing that can help is to increase agent or master logging output. You can read about it here: https://github.com/jenkinsci/remoting/blob/master/docs/logging.md . In summary, if you add a java.util.logging properties file and then reference it via the `-loggingConfig` parameter to the agent. For example something like this: `-loggingConfig jenkins-logging.properties`.

Without further information it is difficult to diagnose anything from this side. Frequently the error is environmental.
 

Closing for lack of sufficient diagnostics and information to reproduce after no response for quite a while.