Jenkins代理JNLP连接问题“无法同步通道上的IO流”和“协议堆栈无法再写入数据”

问题描述

有人知道如何使用JNLP连接处理linux-to-linux Jenkins代理问题吗?

我每20天左右就会看到这些点击。我使用的是centos 7代理主机-具有远程4.2的2.223 jenkins。

我们的工作通过docker插件在临时docker包含文件中运行许多步骤,目前我们使用devicemapper作为docker存储驱动程序。发生这种情况时,似乎docker承受了一定的负担,但我尚无详细的统计数据来支持该理论

docker.image.inside {
...
}

发生这种情况时,主服务器将代理主机报告为脱机,并且它们都仍在具有相同安全组的同一AWS VPC中,因此它们之间的连接性仍然应该是可能的(我上次没有进行检查,因为我们还有其他火灾要处理)。另外,代理Java进程仍在运行。

我听说这可能与插件和复杂的管道代码有关。当我尝试将其与jenkins master的日志进行匹配时,在主机消息中看不到太多信息,也没有看到任何模式。

我还想知道是否切换到ssh代理插件可能使问题减少。我可能会尝试在主机上启用更多日志记录,以期捕获更多详细信息。

如果您看到它或有任何建议,请告诉我您如何处理。

01:51:49 agent.host java: INFO: Failed to synchronize IO streams on the channel hudson.remoting.Channel@...:JNLP4-connect connection to jenkins.edgewise.devops/#.#.#.#:50000
01:51:49 agent.host java: java.lang.InterruptedException
01:51:49 agent.host java: at java.lang.Object.wait(Native Method)
01:51:49 agent.host java: at hudson.remoting.Request.call(Request.java:177)
01:51:49 agent.host java: at hudson.remoting.Channel.call(Channel.java:997)
01:51:49 agent.host java: at hudson.remoting.Channel.syncIO(Channel.java:1730)
01:51:49 agent.host java: at hudson.Launcher$RemoteLaunchCallable$1.join(Launcher.java:1328)
01:51:49 agent.host java: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
01:51:49 agent.host java: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
01:51:49 agent.host java: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
01:51:49 agent.host java: at java.lang.reflect.Method.invoke(Method.java:498)
01:51:49 agent.host java: at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:931)
01:51:49 agent.host java: at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:905)
01:51:49 agent.host java: at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:857)
01:51:49 agent.host java: at hudson.remoting.UserRequest.perform(UserRequest.java:211)
01:51:49 agent.host java: at hudson.remoting.UserRequest.perform(UserRequest.java:54)
01:51:49 agent.host java: at hudson.remoting.Request$2.run(Request.java:369)
01:51:49 agent.host java: at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
01:51:49 agent.host java: at java.util.concurrent.FutureTask.run(FutureTask.java:266)
01:51:49 agent.host java: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
01:51:49 agent.host java: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
01:51:49 agent.host java: at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:117)
01:51:49 agent.host java: at java.lang.Thread.run(Thread.java:748)
02:01:01 agent.host systemd: Created slice User Slice of root.
02:01:01 agent.host systemd: Started Session 784 of user root.

02:15:05 agent.host dhclient[1092]: DHCPREQUEST on eth0 to #.#.#.#ort 67 (xid=0x6...)
02:15:05 agent.host dhclient[1092]: DHCPACK from #.#.#.#xid=0x6...)
02:15:07 agent.host dhclient[1092]: bound to #.#.#.# -- renewal in 1587 seconds.

02:32:00 agent.host java: Oct 23,2020 2:32:00 AM hudson.remoting.Request$2 run
02:32:00 agent.host java: INFO: Failed to send back a reply to the request hudson.remoting.Request$2@...: hudson.remoting.ChannelClosedException: Channel "unkNown": Protocol stack cannot write data anymore. It is not open for write

解决方法

位置:

  • docker未使用推荐的高效存储驱动程序(doc

devicemapper受支持,但在生产环境中需要direct-lvm,因为loopback-lvm虽然为零配置,但性能却很差。 devicemapper是CentOS和RHEL的推荐存储驱动程序,因为它们的内核版本不支持overlay2。但是,当前版本的CentOS和RHEL现在支持overlay2,现在是推荐的驱动程序。

  • Jenkins Docker插件issue #640描述了在Docker负载很高时如何显示InterruptedException

代理主机上的switching storage driver to overlay2似乎是减少此问题风险的正确措施