Jenkins Web 服务器不响应 Ubuntu/Dell PowerEdge R640 中的 HTTP 请求

Question

我有一个系统（“主机”），使用 LXC（即“来宾”）运行多个容器。我已经在来宾中安装了 Jenkins，它们似乎按预期工作，只是它们不响应请求。（我之前已经成功安装过几次 Jenkins，包括 LXC。）在这种情况下，观察到的问题是内置 Jenkins Web 服务器 (Jetty) 没有响应 HTTP 请求，即使这些请求是从 Jenkins 内部发出的。它运行的非常 LXC 来宾，即指向localhost.

我已经努力解决这个问题好几天了，但没有成功。

这是尝试从以下位置联系 Jenkins Web 服务器时得到的结果localhost：

root@base:~# curl -vI http://localhost:8080/jenkins/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> HEAD /jenkins/ HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.58.0
> Accept: */*
>

在工作设置中，您应该收到 HTTP-403，因为您尚未经过身份验证，并且回复时间不会超过一两秒，但即使几个小时后，也没有响应。Jenkins 日志文件也没有报告任何错误。

我需要帮助来找出根本原因并解决此问题，以便 Jenkins 安装按预期工作并变得可访问。

有关于寻找什么/在哪里来找出并解决这个问题的任何指示？

---

以下是我已经研究过的一些事情：

• Jenkins 配置：的配置文件/etc/default/jenkins与我的其他工作设置类似，并且进行了最小的更改（例如仅绑定到本地主机和前缀）。
• Apache 配置：我查看了 Apache 反向代理配置并与其他工作系统进行了比较，但这不是问题。此外，即使从 LXC 容器外部，Apache 也始终可以访问（例如，“它有效！”页面），因此流量不会被防火墙规则阻止。Apache 会因HTTP-502 代理错误而失败，因为 Jenkins 不会回复它。（也就是说，我已经卸载了 Apache 以简化环境。）
• 日志文件： Jenkins 日志文件/var/log/jenkins/jenkins.log不报告任何问题，这些问题通常显示为异常的 Java 堆栈跟踪。
• 防火墙规则 ( iptables -S)：所有链/规则 ( INPUT、FORWARD和OUTPUT) 均设置为ACCEPT。不过，由于此处的通信是在 内部进行的localhost，因此即使存在其他防火墙规则，我也不会期望出现问题。
• 网络数据包和端口 ( netstat -tapon)：显示 Jenkins（java 进程）侦听预期端口（默认 8080，但我尝试过其他端口）；在客户端发送如上所示的请求后，它还显示连接ESTABLISHED（在两端） 。curl这表明 TCP 握手成功。
• 网络流量 ( tcpdump -i lo)：显示正在进行的 3 次握手；它解释了为什么netstat将连接显示为ESTABLISHED。
• 与工作设置进行比较：我安装的其他 Jenkins 具有类似的环境和配置（例如 Ubuntu 18.04 主机、对 Jenkins 配置文件、安装过程的相同更改等）。
• 重现问题：我尝试在其他系统中重现该问题（但失败了）；我使用了完全相同的环境、安装过程、配置等（例如我的笔记本电脑、工作中的单独服务器、家里的单独服务器、相同的 LXC 版本、匹配的来宾操作系统映像指纹等）；在相关生产服务器（Dell PowerEdge R640 服务器）之外，一切都按预期运行。
• ^{从 Orbit 1}破坏系统：我已经多次从头开始销毁/重建所有容器（包括销毁存储所有数据的 ZFS 池）；这没有什么区别。
• 直接在主机中安装：我已经确认直接在主机上安装 Jenkins，即在任何 LXC 容器/来宾之外，也会显示问题。
• 排除 Java/JVM：我可以确认其他基于 Java 的应用程序正常工作，因此它似乎不是影响任何/所有基于 Java 的程序的问题。（我通过设置 Apache Tomcat 服务器对此进行了测试，该服务器按预期工作。）
• 重新定位主机：为了排除潜在的数据中心环境问题，我将服务器移到了我的办公桌区域，在那里我有另一台具有工作设置的测试服务器。这没有什么区别。
• 运行独立 Jetty：我找到了与 Jenkins 捆绑的版本最匹配的 Jetty 服务器版本。无法重现该问题。独立的Jetty服务器按预期响应请求，尽管与 Jenkins 捆绑在一起的服务器仍然没有响应。（Jenkins 的 Jetty 版本如日志中所示。Jetty发布页面jetty-9.4.z-SNAPSHOT; built: 2018-06-05T18:24:03.829Z上没有具有此.z-SNAPSHOT名称的版本，因此我使用了基于构建日期的最接近的匹配项进行此测试：）9.4.11.v20180605
• 从 OpenJRE 切换到 Oracle JRE：已安装/设置要使用的 Oracle JRE（即update-alternatives --config java）。观察到相同的无响应行为。

---

我已经看过但不相关或没有帮助的一些问题：

• 无法访问Jenkins服务器
• 无法使用nginx访问Jenkins
• 使用 SSL 为 Jenkins 和 Sonar 正确配置 Apache 反向代理
• 访问jenkins时出现代理错误
• 反向代理 Linux 容器

我读过的书远不止这些；它们只是一个样本。

---

¹这是唯一可以确定的方法……大多数情况下……

Answer 1

长话短说

如果托管 Jenkins 的系统中有70 个或更多CPU，那么 Jenkins/Jetty 就会卡住并且无法工作。确保 Jenkins 将运行的系统/容器的可用CPU 数量少于 70 个，或者将 Jenkins 安装升级到至少 2.138。2，今天发布（2018-10-10）。

概括

事实证明，詹金斯 2.138。Ubuntu 18.04 LTS 存储库中的 Ubuntu 18.04 LTS 存储库中的 Ubuntu 18.04 LTS 存储库中有一个错误，导致 Jenkins/Jetty 在具有 70 个或更多 CPU 的系统上不响应。詹金斯 2.138。2018 年 10 月 10日今天发布，它修复了几个潜在问题，其中一个问题导致了我遇到的问题。

变更日志在这里。对我来说，关键的修复是这个：

• 使用具有超过 70 个 CPU 的计算机时 Jenkins Web GUI 挂起

我可以确认此错误修复确实解决了问题，并在我的 72 个 CPU 的服务器上验证了这一点。

如果您（还）无法升级 Jenkins 安装，请继续阅读以了解潜在的解决方法。

解决方法（针对容器）

如果您在 LXC 中安装 Jenkins，那么您可以使用以下命令进行控制：

• lxc config set <container> limits.cpu N， 在哪里N < 70; 和
• lxc exec <container> -- systemctl restart jenkins.service

您可能还需要更新配置文件配置，可以执行以下操作：

lxc profile set <container-profile> limits.cpu N

上面已经显示了相同的警告。如果您使用的是虚拟机（例如 VirtualBox、VMware 等），那么您仍然应该能够设置虚拟机可用的 CPU 数量。

PS：感谢 Pavel 的帖子，它引导我找到了正确的方向来处理 CPU/核心计数。