技術文章 » Linux伺服器啟動Tomcat服務瀏覽器無法存取的解決辦法

Linux伺服器啟動Tomcat服務瀏覽器無法存取的解決辦法

2020-10-23 14:00:14

最近在阿里雲買了一臺輕量應用伺服器，但在部署Tomcat啟動服務之後，瀏覽器存取http://[公網IP]:8080時遲遲存取不到。於是我開始了漫長的偵錯之路。

正常情況

1.保證阿里雲安全組開啟了8080埠

在這裡插入圖片描述

2.保證Linux防火牆放行8080埠

# 檢視firewall服務狀態
systemctl status firewalld

# 開啟、重新啟動、關閉、firewalld.service服務
# 開啟
service firewalld start
# 重新啟動
service firewalld restart
# 關閉
service firewalld stop

# 檢視防火牆規則
firewall-cmd --list-all    # 檢視全部資訊
firewall-cmd --list-ports  # 只看埠資訊

# 開啟埠
開埠命令：firewall-cmd --zone=public --add-port=8080/tcp --permanent
重新啟動防火牆：systemctl restart firewalld.service

命令含義：
--zone #作用域
--add-port=80/tcp  #新增埠，格式為：埠/通訊協定
--permanent   #永久生效，沒有此引數重新啟動後失效

#檢視埠是否正常監聽
netstat -an | grep 8080
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN

正常情況下，到這裡，啟動Tomcat服務，瀏覽器就可以存取了，但哪有那麼多正常情況。

非正常情況

1.遇到問題

我來詳細說下我遇到的問題：

  1. 開啟Tomcat服務後，瀏覽器存取不了，一直轉圈圈~

  2. 就在這時我想關閉服務重新啟動，問題來了

    SEVERE: Could not contact localhost:8005. Tomcat may not be running.
SEVERE: Catalina.stop: 
java.net.ConnectException: Connection refused
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
        at java.net.Socket.connect(Socket.java:579)
        at java.net.Socket.connect(Socket.java:528)
        at java.net.Socket.<init>(Socket.java:425)
        at java.net.Socket.<init>(Socket.java:208)
        at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:450)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:400)

        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:487)

2.找到原因

這裡找到原因了，SEVERE: Could not contact localhost:8005. Tomcat may not be running.

也就是說，Tomcat服務還沒有啟動，那麼這個時候我去停止也是停止不了的。那它為什麼沒有啟動還沒有報錯呢？？

這裡其實是不準確的，是因為我們在Tomcat沒完全啟動前就關閉Tomcat。

那麼既然沒報錯，說明服務啟動會成功，那我就等著你成功！

等了6分鐘，終於等到你！

3.探究原理

那麼現在也就是說，我們操作沒毛病，只是這個服務啟動的太慢了。

可，為什麼這麼慢嘞？？？

我檢視了一下程序，Tomcat所在的JVM程序已經被啟動了所以可以排除是JVM退出引起的問題。那麼問題真的就是JVM因為某種原因被阻塞了。

分析

程式被阻塞一般來說一定是要等待某個資源，而現在的情況是所有資源都充足，仔細想想我需要找到Tomcat停止在了哪裡？程式碼裡發生了什麼事情。我決定試一下 strace，這是一個跟蹤系統呼叫(System Call)的工具，無論是Java還是Pyhton很多資源申請都會變成System Call。（比如開啟檔案、新建執行緒、讀寫資料、等待I/O）通過這個工具我至少可以知道Tomcat是停止在哪個System Call上的，這樣可以方便我推斷出問題的原因。

在我尋找問題的時候，他又啟動好了，所以我們先把它關閉。

./shutup.sh

然後進行跟蹤

strace -f -o strace.out ./catalina.sh run

strace有很多引數，我用了兩個引數

  • -f 跟蹤fork的子程序，通俗的說會跟蹤所有執行緒的系統呼叫
  • -o把內容輸出到檔案

這一步結束後我們來看看結果。

cat strace.out

分析的方法是從下往上（被阻塞的地方肯定是在最後咯）。首先我們需要去掉Tomcat停止引起的System Call，它們不是我們需要的。從後往前搜尋找到SIGINT。

在這裡插入圖片描述

紅色部分以上就是引起阻塞的系統呼叫了，上面有一大堆一大堆的futex的呼叫，它們是Linux中的一種輕量級的同步方法，所以我們可以判斷出最上面肯定是有某個System Call就是阻塞的真正元凶。跳過所有的futex：

在這裡插入圖片描述

這個read就是引起後面一串futex的真正原因，strace非常聰明它不僅僅給出了System Call還給出了傳遞的引數和返回值，read讀取的是61號檔案控制程式碼，沒有返回成功(unfinished)。

順著這條路，我們看一下61號檔案控制程式碼是什麼：

在這裡插入圖片描述

/dev/random是Linux下的隨機函數生成器，讀取它相當於生成亂數字。

搜尋它，簡單來說就是，/dev/random的亂數生成依賴系統環境噪聲，如滑鼠、鍵盤操作等。
當噪聲資料不夠的時候，就會出現讀取阻塞。

深入分析

如果用Tomcat /dev/random作為關鍵字基本上就能夠回答我們的疑惑了。Tocmat的Session ID是通過SHA1演演算法計算得到的，計算Session ID的時候必須有一個金鑰。為了提高安全性Tomcat在啟動的時候會通過隨機生成一個金鑰。這個亂數是通過 linux的提供的隨機函數生成器提供永不為空的隨機位元組資料流，許多加密解密程式需要用到它們提供的亂數。

解決問題

明白了問題的原因解決起來就非常簡單了——替換/dev/random為/dev/./urandom，用偽隨機函數生成器(/dev/./urandom)來替代隨機函數生成器(/dev/random)。

  • 通過修改Tomcat啟動檔案catalina.sh
    –Djava.security.egd=file:/dev/./urandom
  • 通過修改JRE中的java.security檔案securerandom.source=file:/dev/./urandom

4.徹底解決問題

在Linux（CentOS）環境下，亂數可以從兩個特殊的檔案中產生，一個是/dev/urandom，另外一個是/dev/random。

它們產生亂數的原理是利用當前系統的熵池來計算出固定一定數量的隨機位元，然後將這些位元作為位元組流返回。熵池就是當前系統的環境噪音，熵指的是一個系統的混亂程度，系統噪音可以通過很多引數來評估，如記憶體的使用，檔案的使用量，不同型別的程序數量等等。

上面介紹的兩種方式都是用/dev/urandom替換/dev/random，其實還有第三種方式——增大/dev/random的熵池。問題的原因是由於熵池不夠大，所以增大它是最徹底的方法。

通過以下命令，我們可以檢視現在的熵池大小；

cat /proc/sys/kernel/random/entropy_avail
189

我們需要找到一種方式來提高這個值就行了。如果你的CPU帶有DRNG特性，可以充分利用硬體來提高熵池產生的速度 。

通過cat /proc/cpuinfo | grep rdrand可以檢視自己的CPU是否支援，一般來說Intel的Ivy_Bridge架構的CPU都支援（i3、i5需要注意是否採用該種架構，i7和xeon基本上都支援）；AMD的CPU在2015年以後生成的都支援。（如果你是虛擬機器器需要開啟額外的引數)。如果你的硬體不支援，也沒有關係，我們可以讓/dev/urandom來做「熵源」。

以Centos7為例，

  • yum install rngd-tools(或者rng-tools)安裝rngd服務（熵服務）

  • systemctl start rngd啟動服務（支援DRNG特性的同學，到這裡就可以cat /proc/sys/kernel/random/entropy_avail檢視了）

    cat /proc/sys/kernel/random/entropy_avail
3009

  • 如果你的CPU不支援DRNG特性，可以使用/dev/unrandom來模擬。

  • cp /usr/lib/systemd/system/rngd.service /etc/systemd/system

  • vim /etc/systemd/system/rngd.service

  • ExecStart=/sbin/rngd -f -r /dev/urandom

  • systemctl daemon-reload重新載入服務

  • systemctl restart rngd重新啟動服務

5.選擇哪種解決方法

個人建議選擇第三種方式，熵池不僅僅Tomcat用，Linux下的所有應用程式產生亂數都會用到這個，所以不僅僅是Tomcat可能被阻塞。如果你搜尋會發現Apache、Nginx、OpenSSL都被這個問題坑過。如果我們通過修改Java的設定來解決這個問題其實只是解決Java應用程式的問題，只能是治標不治本。根治的方法應該是通過rngd提高亂數生成的速度。

6.如何重現故障

可以很容易的重現上面描述的故障

  • systemctl stop rngd 停止rngd服務（如果你有啟動rngd）
  • 檢視當前熵池的大小cat /proc/sys/kernel/random/entropy_avail
  • head -c1024 /dev/random，強制消費1024個亂數，系統會長時間沒有反應。直接ctrl+c
  • 再次檢視熵池的大小cat /proc/sys/kernel/random/entropy_avail，保證它的大小在儘可能的小
  • 啟動tomcat，會發現又是很長時間的等待