ssl - Jenkins Windows 从属连接因 java.nio.channels.ClosedChannelException 而终止

Question

在作为从机连接到 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)

score 15 · Accepted Answer

我遇到了与我的奴隶连接断开的 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

score 10 · Accepted Answer

在我们的 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-Bit Server VM (build 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-Bit Server VM (build 25.121-b13, 混合模式)
当 slave 上的 java 更新到 Java 8 后，连接问题就消失了。

score 6 · Accepted Answer

除了帖子中的错误日志，我还得到了从站 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 中为所有用户关闭服务控制台 - 这是必须的。由于某种原因，微软正在锁定 Windows 服务的安装/删除

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

3）windows从属级别：从cmd中删除jenkins从属服务（如果存在）：（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 空闲超时增加到（从） - 就像@njtman 建议的那样60060

7）jenkins master ui level：在jenkins中重新启动代理并等待几分钟。

我的环境：

詹金斯：2.89.2，操作系统：Windows 2012 R2，Java：jdk1.8.0_151

score 5 · Accepted Answer

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

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

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

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

完成此程序后应该没问题

score 1 · Accepted Answer

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

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

重新连接

score 1 · Accepted Answer

在 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

score 1 · Accepted Answer

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

问题

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

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

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

解决方案

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

更新 Java 版本。

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

我删除了每个 jenkins-slave.* 文件，只留下 jenkins_agent.pid 文件和文件夹“remoting”和“workspace”。
从 Web 浏览器转到 Jenkins 上的从节点界面，然后单击按钮。

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

希望能帮助到你！

score 0 · Accepted Answer

没有时间为虚拟奴隶呼吸......

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

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

因此，如果 libvirt-client (slave) 正在向 jenkins打招呼，您可能应该等待几秒钟让这个可怜的家伙喘口气。开机后。

从机是win7主机是ubuntu 18.04

score -1 · Accepted Answer

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

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

score -1 · Accepted Answer

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

ssl - Jenkins Windows 从属连接因 java.nio.channels.ClosedChannelException 而终止

10 回答 10

问题

解决方案

没有时间为虚拟奴隶呼吸......

Related

Reference