如何解决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似乎是减少此问题风险的正确措施