【问题标题】：Jenkins Windows slave connection getting terminated with java.nio.channels.ClosedChannelExceptionJenkins Windows 从属连接因 java.nio.channels.ClosedChannelException 而终止
【发布时间】：2021-11-24 21:12:28
【问题描述】：

当连接到 Windows 机器作为从机时，我收到以下错误，我认为这是一些与网络相关的问题，但需要一些帮助，从哪里开始寻找或有什么可能的解决方案。

INFO: Terminated
Aug 01, 2017 10:15:54 PM hudson.remoting.JarCacheSupport$1 run
WARNING: Failed to resolve a jar 06bcb4519543f5ec83cf9d6da9f6cfbe
java.io.IOException: Failed to write to C:\Users\Administrator\.jenkins\cache\jars\06\BCB4519543F5EC83CF9D6DA9F6CFBE.jar
        at hudson.remoting.FileSystemJarCache.retrieve(FileSystemJarCache.java:133)
        at hudson.remoting.JarCacheSupport$1.run(JarCacheSupport.java:64)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:483)
        at java.util.concurrent.FutureTask.run(FutureTask.java:274)
        at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110)
        at java.lang.Thread.run(Thread.java:809)
Caused by: java.io.IOException: Backing channel 'JNLP4-connect connection to dr2r4m1p21/172.20.238.41:9001' is disconnected.
        at hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.java:192)
        at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:257)
        at com.sun.proxy.$Proxy4.writeJarTo(Unknown Source)
        at hudson.remoting.FileSystemJarCache.retrieve(FileSystemJarCache.java:98)
        ... 5 more
Caused by: java.nio.channels.ClosedChannelException
        at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.onReadClosed(ChannelApplicationLayer.java:208)
        at org.jenkinsci.remoting.protocol.ApplicationLayer.onRecvClosed(ApplicationLayer.java:222)
        at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:832)
        at org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.java:287)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.java:181)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.switchToNoSecure(SSLEngineFilterLayer.java:283)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processWrite(SSLEngineFilterLayer.java:503)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processQueuedWrites(SSLEngineFilterLayer.java:248)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.doSend(SSLEngineFilterLayer.java:200)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.java:166)
        at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:832)
        at org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.java:154)
        at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer.access$1500(BIONetworkLayer.java:48)
        at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader.run(BIONetworkLayer.java:247)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
        at hudson.remoting.Engine$1$1.run(Engine.java:94)
        ... 1 more

上面提到的堆栈跟踪来自药膏（Windows）机器，我的 Jenkins/Master 正在 RHEL 上运行，我可以在那里看到以下堆栈跟踪。

INFO: Accepted JNLP4-connect connection #113 from /172.20.238.31:60363
Aug 01, 2017 12:45:55 PM jenkins.slaves.DefaultJnlpSlaveReceiver channelClosed
WARNING: Computer.threadPoolForRemoting [#42] for Build_Agent terminated
java.nio.channels.ClosedChannelException
        at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.onReadClosed(ChannelApplicationLayer.java:208)
        at org.jenkinsci.remoting.protocol.ApplicationLayer.onRecvClosed(ApplicationLayer.java:222)
        at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:832)
        at org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.java:287)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.java:181)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.switchToNoSecure(SSLEngineFilterLayer.java:283)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processWrite(SSLEngineFilterLayer.java:503)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processQueuedWrites(SSLEngineFilterLayer.java:248)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.doSend(SSLEngineFilterLayer.java:200)
        at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.doCloseSend(SSLEngineFilterLayer.java:213)
        at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.doCloseSend(ProtocolStack.java:800)
        at org.jenkinsci.remoting.protocol.ApplicationLayer.doCloseWrite(ApplicationLayer.java:173)
        at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer$ByteBufferCommandTransport.closeWrite(ChannelApplicationLayer.java:311)
        at hudson.remoting.Channel.close(Channel.java:1295)
        at hudson.remoting.Channel.close(Channel.java:1263)
        at jenkins.slaves.DefaultJnlpSlaveReceiver.afterChannel(DefaultJnlpSlaveReceiver.java:173)
        at org.jenkinsci.remoting.engine.JnlpConnectionState$4.invoke(JnlpConnectionState.java:421)
        at org.jenkinsci.remoting.engine.JnlpConnectionState.fire(JnlpConnectionState.java:312)
        at org.jenkinsci.remoting.engine.JnlpConnectionState.fireAfterChannel(JnlpConnectionState.java:418)
        at org.jenkinsci.remoting.engine.JnlpProtocol4Handler$Handler$1.run(JnlpProtocol4Handler.java:334)
        at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

【问题讨论】：

你检查过slave jar在windows机器上是否成功运行
slave jar 运行成功，当我尝试在 slave 机器上运行 slave.jar 时，我可以看到 slave 试图连接到 master，然后停止上面提到的堆栈跟踪和 java.nio.channels .ClosedChannelException
你在jenkins中使用的是固定端口还是随机JNLP端口？？
fixed 9001..，我认为这可能是端口和安全问题，但我不知道从哪里开始！
重启我的jenkins服务器解决了这个问题。

标签： ssl jenkins nio jenkins-slave

【解决方案1】：

我遇到了与我的奴隶连接断开的 OP 类似的错误。问题的根本原因不是 Jenkins 从属主机和主控主机之间的 Java 版本不匹配。

解决方案 如果您在 AWS 上的 Elastic Load Balancer (ELB) 后面的 EC2 实例中运行 Jenkins，请将“属性”部分下的“空闲超时”值从默认的 60 秒增加。我将新值设置为 600 并且不再遇到错误。

如果您的构建过程中的单个命令花费超过 60 秒且没有日志输出，则 ELB 将由于空闲活动而终止会话。

来源：https://issues.jenkins-ci.org/browse/JENKINS-44001?focusedCommentId=312412&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-312412

【讨论】：

这正是我的问题所在。谢谢！
谢谢，我将 AWS 与经典 ELB 结合使用，遇到了这个问题。
AWS ELB 背后有 Jenkins，这也解决了我的问题！

【解决方案2】：

更新我们的 jenkins master 后，我发现了同样的错误。这可能是由于 Java 7 (v80) 和最新的 Java 8 不兼容造成的。
检查您的 master 使用的 java 版本，以及您的 slave 的 java 版本。
就我而言，我在 linux 主机上运行 swarm-client-2.0-jar-with-dependencies.jar，它使用的是 Java 7。

java 版本 "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64 位服务器 VM（内部版本 24.80-b11，混合模式）
我们的 jenkins master 已经升级，现在正在运行 Java 8

java 版本 "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64 位服务器 VM（内部版本 25.121-b13，混合模式）
slave 上的 java 更新到 Java 8 后，连接问题就消失了。

【讨论】：

* 请注意，Java 7 不再接收公共更新：java.com/en/download/faq/java_7.xml
这个问题的主题是关于 slave 代理，但这里有一些关于从属和 master 之间的 maven java 要求的有用信息：@987654322 @ 在 Maven 作业和 Java 版本兼容性部分。
master有1.8.211，slave有1.8.311版本会不会有问题？

【解决方案3】：

除了帖子中的错误日志，我还得到了slave中jenkins目录下的错误日志（对我来说是C:\jenkins\jenkins-slave.err.log）：

JNLP 文件 http://jenkins.domain.com/computer/my_slave_name/slave-agent.jnlp?encrypt=true 有无效参数：[#####################################, my_slave_name, -workDir, c:\jenkins, -internalDir, 远程处理, -url, http://jenkins.domain.com/，-headless，-jar-cache， C:\Users\Administrator.jenkins\cache\jars] 很可能是主“-workDir”中的配置错误不是有效选项

我的解决方案：

1)windows 从属级别：关闭所有用户在 GUI 中的 services 控制台 - 这是必须的。由于某种原因，Microsoft 正在锁定 Windows 服务的安装/删除

2)windows 从属级别：杀死所有 java 和 jenkins-slave 进程（如果存在）

3)windows 从属级别：删除 jenkins slave 服务（如果存在）从 cmd：sc delete jenkinsslave-c__jenkins /force（在我的情况下）

4)windows 从属级别：验证您是否安装了 java 8：我正在使用 jdk1.8.0_151 。卸载所有旧java版本

5)jenkins master ui level：在slave configure下更改Jenkins连接slave的方式 --> Launch method：Let Jenkins control this Windows slave as a Windows service（而不是Launch agent via Java Web Start）

6) aws 级别：增加 aws elb Idle timeout 到600（来自60） - 就像@njtman 建议的那样

7)jenkins master ui 级别：重新启动 jenkins 中的agent 并等待几分钟。

我的环境：

jenkins：2.89.2，操作系统：windows 2012 R2，java：jdk1.8.0_151

【讨论】：

【解决方案4】：

我遇到了同样的问题。我发现如果您的作业没有针对 GUI 运行，Windows 从站会切换到“睡眠”模式。

对于 Windows...没有移动鼠标或键盘意味着没有活动。

然后就成功解决了。在 Windows7 从站上，这是我所做的：

控制面板\硬件和声音\电源选项
显示附加计划
选择高性能
控制面板\硬件和声音\电源选项\编辑计划设置
从不关闭显示
更改高级电源设置 -->10000 分钟后关闭硬盘

这个过程应该没问题

【讨论】：

【解决方案5】：

在 Windows 上，我意识到我需要将“-noCertificateCheck”属性添加到工作目录中 jenkins-slave.xml 的参数中。我们在主服务器上使用来自内部 PKI 的证书，这是解决它的最简单方法（将所有内容都放在内部网络中）。

<arguments>-Xrs  -jar "%BASE%\slave.jar" -jnlpUrl https://jenkins.ourdomain.com/computer/Windows%20build%20server%20-%20Bare%20metal/slave-agent.jnlp -secret abc -noCertificateCheck</arguments>

我通过在命令提示符下手动运行代理来识别这一点：

java -jar agent.jar -jnlpUrl https://jenkins.ourdomain.com/computer/Windows%20build%20server%20-%20Bare%20metal/slave-agent.jnlp -secret abc -workDir "D:\agentroot" -noCertificateCheck

【讨论】：

【解决方案6】：

嗯...对我来说，它适用于以下解决方案：

将节点标记为“临时离线”并再次将其重新“在线”

重新连接

【讨论】：

【解决方案7】：

user2015131 的建议启发了我找到解决此问题的方法。

问题

我解释一下我的情况，它可能对某些人有用：

我很久以前在我的从属计算机上安装了 Jenkins 作为服务。
我更新了 Jenkins 主计算机上的 Java。

所以存储在slave上的Jenkins服务的代码已经过时了。

解决方案

在每台从机上执行以下步骤：

更新 Java 版本。

确保 Java 版本与主计算机上安装的版本相同或兼容。
删除旧的从属代码。它位于节点配置下的远程根目录字段中指定的文件夹内。

我删除了所有 jenkins-slave.* 文件，只留下 jenkins_agent.pid 文件以及文件夹“remoting”和“workspace”。
从网页浏览器进入Jenkins的从节点界面，点击按钮。

您将下载一个新的 JNLP 文件以在从属计算机上安装一个新的（更新的）Jenkins 服务。
运行下载的文件，进入菜单并点击“作为服务安装”。

希望对你有帮助！

【讨论】：

【解决方案8】：

虚拟奴隶没时间喘口气……

好的，我是如何解决我的特殊情况的：

我有一些带有 libvirt/quemu 的 VM 作为从属设备运行。因为 libvirt-plugin 对我来说不可靠，所以我自己启动了这些 VM。我问自己：“为什么这个 libvirt-plugin 有强制的延迟时间……不耐烦……

因此，如果 libvirt-client（从属）正在向 jenkins 打招呼 hello，您可能应该等待几秒钟，让这个可怜的家伙喘口气。启动后。

从机是win7主机是ubuntu 18.04

【讨论】：

【解决方案9】：

我遇到了同样的问题，使用以下步骤进行了纠正

转到 Jenkins Url -> Manage Jenkins -> Node -> Your Node ..you will get Custom WorkDir path let say C:/Jenkins
打开 WorkDir Path 并删除完整的远程处理目录
重新启动从站

【讨论】：

【解决方案10】：

在我的情况下很简单，首先我的主节点服务器重新启动。而其他devops人员可能会在master中重新启动jenkins代理服务。所以我不得不在slave节点中重新启动jenkins slave服务。而且它确实奏效了。

【讨论】：