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

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

上面提到的堆栈跟踪来自salve（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)

Answer 1

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

<强>解决方案如果您在Elastic Load Balancer（ELB）后面的AWS上的EC2实例中运行Jenkins，请增加＆＃34;空闲超时＆＃34; ＆＃34;属性下的值＆＃34;部分默认为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

Answer 2

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

java版＆＃34; 1.7.0_80＆＃34; Java（TM）SE运行时环境（构建 1.7.0_80-b15）Java HotSpot（TM）64位服务器VM（内置24.80-b11，混合模式）
我们的jenkins master已升级，现在正在运行Java 8

java version＆＃34; 1.8.0_121＆＃34; Java（TM）SE运行时环境（构建 1.8.0_121-b13）Java HotSpot（TM）64位服务器VM（版本25.121-b13，混合模式）
当奴隶上的java更新为Java 8时，连接问题就消失了。

Answer 3

除了帖子中的错误日志，我还得到了奴隶中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，remoting，-url， http://jenkins.domain.com/，-headless，-jar-cache， C：\ Users \ Administrator.jenkins \ cache \ jars]很可能是一个 master中的配置错误＆＃34; -workDir＆＃34;不是有效选项

我的解决方案：

1）Windows奴隶级别：关闭所有用户的GUI中的服务控制台 - 这是必须的。由于某种原因，微软正在锁定Windows服务的安装/删除

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

3）windows slave级别：删除来自cmd的{strong> jenkins slave 服务（如果存在）：sc delete jenkinsslave-c__jenkins /force（在我的情况下）

4）windows slave level：验证您安装了 java 8 ：我正在使用jdk1.8.0_151。卸载所有旧 java版

5）jenkins master ui level：在slave configure下更改Jenkins连接到slave的方式 - ＆gt;启动方法：Let Jenkins control this Windows slave as a Windows service（而不是Launch agent via Java Web Start）

6）aws级别：将 aws elb空闲超时增加到600（来自60） - 比如@njtman建议

7）jenkins掌握ui级别：重新启动 jenkins中的代理并等待几分钟。

我的环境：

jenkins：2.89.2，os：windows 2012 R2，java：jdk1.8.0_151

Answer 4

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

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

然后成功解决它。在Windows7奴隶上，我就是这样做的：

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

此程序后应该没问题

Answer 5

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

问题

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

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

因此，存储在从属服务器上的Jenkins服务的代码已过时。

解决方案

在每台从属计算机上遵循以下步骤：

更新Java版本。

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

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

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

希望有帮助！

Answer 6

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

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

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

因此，如果libvirt-client（奴隶）对jenkins说 hello ，您可能应该等待几秒钟，让这个可怜的家伙喘口气。启动后。

奴隶是win7主机，ubuntu 18.04

Answer 7

在Windows上，我认识到我需要在工作目录中jenkins-slave.xml的参数中添加“ -noCertificateCheck”属性。我们使用来自主机上内部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

Answer 8

嗯...对我来说，它可以解决以下问题：

将节点标记为“临时脱机”，然后再次将其放回“在线”

重新连接

Answer 9

我也遇到了同样的问题，请按照以下步骤进行纠正

转到Jenkins网址->管理Jenkins->节点->您的节点..您将获得Custom WorkDir路径，说C：/ Jenkins
打开WorkDir路径并删除完整的远程目录
重新启动奴隶

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

9 个答案:

问题

解决方案

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