工作問題案例裝置關機變重啟

最近處理一現場反饋時，有遇到關機變重啟的問題。現象是執行關機命令，但是卻因為某種原因變為了重啟，復現的概率非常大。

最開始的懷疑方向在軟體層面，做了如下嘗試：

使用其它的關機命令

無效使用關機命令的不同引數

無效使用 sysrq 的關機命令

sysrq 關機可以執行如下命令，經過確認現場的裝置核心配置未開啟 sysrq-trigger 功能。

echo 1 > /proc/sys/kernel/sysrq;
echo o > /proc/sysrq-trigger

嘗試自己編寫程式呼叫 reboot 系統呼叫關機

這是我在閱讀關機操作相關的系統呼叫後提出的乙個方案，實際上與通過 sysrq 關機方式的過程大致相同。同樣無效！

更換裝置

新更換的裝置也能夠復現相同的問題！

嘗試更換機器的系統測試

更換其它產品的系統，發現能夠正常關機！

在初步定位過程中，更換其它系統後能夠正常關機，能夠大概率排除硬體問題，猜測可能是在關機的過程**現了某種異常導致了問題。

要驗證這一點也非常簡單，給裝置接上串列埠，繼續關機檢視串列埠輸出也許能夠看出一些端倪。可是測試的時候卻發現串列埠沒有核心相關的列印內容，這不太合理。

首先檢視系統中的 printk 列印級別，內容如下：

$ cat /proc/sys/kernel/printk 0 4 0 0

看到這個輸出資訊有點驚訝，console_level 竟然被設定為 0，怪不得串列埠沒有核心相關的列印資訊呢。

於是首先在產品的關機流程中新增如下命令降低印表機別：

echo "7 4 7 4" > /proc/sys/kernel/printk

修改完成後繼續關機，復現問題後檢視串列埠資訊發現了如下資訊：

eth0 發包超時，核心 oops 了，猜測這個問題可能就是關機變重啟的關鍵所在。

對這個問題進行分析，應該是在 acpi 切換了電源狀態時，eth0 還在發包，而此時由於電源狀態的改變，硬體已經不能處理了，就導致發包超時，核心 crash，進而導致看門狗重啟系統。

上文中描述的 eth0 發包超時核心 oops 的問題之前有遇到過，不過卻是在開機時產生的。在這個問題出現後介面便一直無法發包，規避方案是執行一次 down、up。

在這個場景中，問題是在關機的時候出現的，與我之前遇到的情況有所區別。不過從 dmesg 資訊看，真正的問題應該是為什麼 acpi 切換電源狀態的時候 eth0 還在收發包？

這個問題其實跟我們定製化的系統有關係，我們的系統並不像常見的發行版那樣通過 network-manager、networking 這些服務來管理網路，也不會在關機的時候通過這些服務來關閉網路，這才是真正的問題所在！

於是我在產品的關機流程中新增了如下命令：

awk -f: '/:/' /proc/net/dev |
xargs -i ifconfig
'{}' down

這一命令將會 down 掉所有的網路介面，介面 down 掉後自然也就不會再發包了，測試確定問題得到解決！寫這篇文章的時候，我發現在這個問題的定位過程我們忽略了乙個非常重要的資訊，這個資訊就是正常關機時的 dmesg 資訊。

正常關機時的 dmesg 資訊貼到下面：

[  186.343205] ixgbe 0000:09:00.1: pci int b disabled
[ 186.359127] ixgbe 0000:09:00.0: pci int c disabled
[ 186.375103] ixgbe 0000:05:00.1: pci int b disabled
[ 186.390073] ixgbe 0000:05:00.0: pci int c disabled
[ 186.419584] igb 0000:04:00.3: pci int d disabled
[ 186.434757] igb 0000:04:00.3: refused to change power state, currently in d0
[ 186.455482] igb 0000:04:00.2: pci int c disabled
[ 186.470654] igb 0000:04:00.2: refused to change power state, currently in d0
[ 186.491379] igb 0000:04:00.1: pci int b disabled
[ 186.506551] igb 0000:04:00.1: refused to change power state, currently in d0
[ 186.527276] igb 0000:04:00.0: pci int a disabled
[ 186.542482] igb 0000:04:00.0: refused to change power state, currently in d0
[ 186.549569] ehci_hcd 0000:00:1d.0: pci int a disabled
[ 186.554628] ehci_hcd 0000:00:1a.0: pci int a disabled
[ 186.559707] acpi: preparing to enter system sleep state s5
[ 186.565669] disabling non-boot cpus ...
[ 186.686212] power down.

倒數三行資訊挺關鍵，從 acpi 切換系統電源狀態到 s5，再到關閉所有的非引導 cpu，最後列印 power down 表示關機完成，本文描述的問題中，power down 這一行就沒有列印，替代的內容就是 eth0 發包超時的核心堆疊資訊。

上面貼出的資訊中另外乙個可能存在問題的點是 igb 的幾個介面拒絕切換電源狀態，仍舊保持 d0 這一完全執行狀態，也許跟 bypass 有些關係，不進一步深究了！

從本文中的描述中可以看出這個問題並不太難，甚至於僅僅只修改了一行**就解決了問題，但在此之前已經花了兩周左右的時間。

一開始產品找我看的時候也只提供了關機指令碼的列印資訊，問題前期定位完全沒有關注到 dmesg 的列印資訊，當補上了 dmesg 的資訊後，真正的問題才浮出了水面。

最後不得不提的是基線資料，在這個問題中，oops 的內容指向性很強，有沒有基線資料在這個問題中無足輕重。可如果問題不這麼明顯，這時候基線資料就變得非常重要了，缺少這個資料問題就變得不那麼容易解決了！我們應該有意識的收集基線資料，它也是我們能夠從乙個個問題中挖掘出的價值所在！

工作問題案例裝置關機變重啟

華為裝置NAT配置案例

工作動機案例研究

工作壓力案例研究

工作問題案例 裝置關機變重啟

華為裝置NAT配置案例

工作動機 案例研究

工作壓力 案例研究

相關推薦

工作問題案例裝置關機變重啟

工作動機案例研究

工作壓力案例研究