Jenkins Web 伺服器未響應 Ubuntu/Dell PowerEdge R640 中的 HTTP 請求
我有一個使用 LXC（即“客人”）執行多個容器的系統（“主機”）。我已經在客人體內安裝了 Jenkins，它們似乎按預期工作，只是它們不響應請求。（我之前已經成功安裝了幾次 Jenkins，包括 LXC。）在這種情況下，觀察到的問題是內置的 Jenkins Web 伺服器（Jetty）沒有響應 HTTP 請求，即使這些請求是從內部發出的。非常 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與我的其他工作設置類似，並且更改很小（例如僅綁定到 localhost 和前綴）。- **Apache 配置：**我查看了 Apache 反向代理配置並與其他工作系統進行了比較，但這不是問題。此外，Apache 總是可以訪問的（例如“It works!”頁面），即使是從 LXC 容器之外，所以流量不會被防火牆規則阻止。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 容器
我讀過的遠不止這些；他們只是一個樣本。
1這是唯一可以確定的方法……主要是……
TL;博士
如果託管 Jenkins 的系統中有70 個或更多CPU，那麼 Jenkins/Jetty 就會卡住並且無法工作。確保執行 Jenkins 的系統/容器的可用 CPU少於 70個，或者將您的 Jenkins 安裝至少升級到 2.138。2，今天（2018-10-10）發布。
概括
事實證明，詹金斯 2.138. Ubuntu 18.04 LTS 儲存庫中的1有一個錯誤，導致 Jenkins/Jetty 在具有 70 個或更多 CPU 的系統上無響應。詹金斯 2.138。2於 2018 年 10 月 10 日今天發布，其中包括對幾個潛在問題的修復，其中一個導致我遇到的問題。
變更日誌在這裡。對我來說關鍵的修復是這個：
我可以確認這個錯誤修復確實解決了這個問題，並在我的 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 等），那麼您應該仍然能夠設置 VM 可用的 CPU 數量。
**PS：**感謝 Pavel的文章，這使我在正確的方向上玩 CPU/Core 計數。
這是對同一問題的更詳細說明 https://issues.jenkins-ci.org/browse/JENKINS-33412
以前的 Jenkins 版本將底層碼頭使用的執行緒數限制為 40（handlerCountMax 選項）。預設情況下，jetty 使用 Runtime.getRuntime().availableProcessors()/2 執行緒作為選擇器。如果 CPU 核心數足夠高（例如 70）或 jetty ssl 連接器也已啟動並且 CPU 核心數超過 36，則執行緒耗盡並且 http 請求卡住了。考慮遷移到最新的詹金斯並手動定義碼頭的執行緒數 - 檢查這些碼頭參數 - qtpMaxThreadsCount、jettyAcceptorsCount、jettySelectorsCount。