有人知道如何通过 JNLP 连接处理 Linux 到 Linux Jenkins 代理问题吗？
我每隔 20 天左右就会看到这些点击。我正在使用 centos 7 代理主机 - 2.223 jenkins 和远程处理 4.2。
我们的作业通过 docker 插件在临时 docker 中运行许多步骤，目前我们使用 devicemapper 作为我们的 docker 存储驱动程序。当这种情况发生时，docker 似乎确实承受了一些负载，但我还没有详细的统计数据来支持该理论
docker.image.inside {
...
}
发生这种情况时，控制器会报告代理主机处于离线状态，并且两者仍然位于具有相同安全组的同一 AWS VPC 中，因此它们之间的连接应该仍然是可能的（我上次没有检查它，因为我们还有其他火来处理）。此外，代理 java 进程仍在运行。
我听说这可能与插件和复杂的管道代码有关。我在主机消息中没有看到太多内容，并且当我尝试将其与 Jenkins 控制器的日志进行匹配时，还没有看到任何模式。
我还想知道切换到 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
鉴于：
支持devicemapper，但生产环境需要direct-lvm，因为loopback-lvm虽然是零配置，但性能非常差。 devicemapper是CentOS和RHEL的推荐存储驱动程序，因为它们的内核版本不支持overlay2。但是，当前版本的 CentOS 和 RHEL 现在支持 Overlay2，这是现在推荐的驱动程序。
看来在代理主机上将存储驱动程序切换到overlay2是降低此问题风险的正确操作