?在技術支持群，看到有用戶報了一個不明原因的重啟問題。 重啟現(xiàn)象是 ——有極個別設備在工作中不定時反復異常重啟，大部分設備正常；反復重啟設備，有時候又能持續(xù)正常工作。

隔著屏幕都感覺到了客戶的著急和無奈，我決定和這位用戶一起揪出這個“搗蛋鬼”。

一、查找線索

按常規(guī)流程先詢問用戶開發(fā)模塊、開發(fā)方式，并要求提供對應日志。經(jīng)確認如下：

開發(fā)模塊：Air780E

最新資料：www.air780e.cn

開發(fā)方式：LuatOS

開發(fā)教程：

https://doc.openluat.com/wiki/26?wiki_page_id=3020

客戶提供日志反饋：

腳本日志沒報錯誤，就是不定時卡住一會，然后就重啟了。

第一反應：不會是死循環(huán)導致的重啟吧？

用戶反饋：“沒有死循環(huán)，任務里面都有延時的，而且大部分設備是正常的。且重啟的時間也不定，最短4秒，最長是三分多鐘，看起來不符合20秒的看門狗重啟呀，而且設備昨天有正常工作一天，然后異常的時候就持續(xù)一直異常。但是這個固件的絕大部分設備是正常工作，不會異常重啟的?！?/p>

看來不是死循環(huán)導致的看門狗重啟問題。

為了進行一步排查重啟原因，我讓用戶用pm.lastReson()這個接口打印開機原因值。

客戶反饋：“我們有平臺上傳數(shù)據(jù)， pm.lastReson()是006異常重啟 ”。

根據(jù)接口文檔相關說明來看，確實不是內(nèi)部看門狗導致的重啟，是異常重啟導致的。

接口文檔詳見：

https://wiki.luatos.com/api/pm.html#pm-lastreson

二、了解背景

心想看不出啥具體原因，先了解一下客戶使用背景吧，說不定會有啥線索。

我問：“之前正常，現(xiàn)在是用不了，一直在重啟嗎？”

客戶反饋：“也不是吧，一開始是好的，然后掛了幾個月一直重啟，最近發(fā)現(xiàn)，昨天我拿過來掛了一天又正常，然后今天又重啟，老化區(qū)就這個設備會重啟，其他同固件是正常的?！?/p>

我又問：“換DEMO會重啟嗎？ 確認一下是硬件問題，還是軟件問題。 ”

客戶反饋：“ 今天測試過，只下載腳本是一定會出問題。 然后我剛剛重新下載底層和腳本，目前五分鐘沒有重啟?！?/p>

看上去應該不是硬件問題，可能是軟件引起的。心想讓客戶用最新版本試一下吧，確認一下還會不會出現(xiàn)問題。

客戶反饋：“我們是因為有一個設備到客戶手上有這個問題是V1108的，然后老化區(qū)只有這個設備也是異常重啟，是V1106的，然后就看的這個，后面重新燒錄1106的底層也是正常的，這設備挺難出現(xiàn)這個問題的，只能我們這邊掛著測一下?！?/p>

看來又是一個令人頭大的重啟問題，要等客戶提供底層日志來進一步排除問題了。

三、重要線索

客戶把掛測的底層日志提供過來了，打開后確實看到了RamDumpData開頭的死機信息。

打開上面的RamDumpData出現(xiàn)如下信息：

我趕緊和研發(fā)大佬確認，可能是啥情況。大佬問答大概率是FLASH壞掉了，讓和客戶確認不是有KV相關的操作。

客戶回答，確實有KV的操作。

本文提到的KV：

KV數(shù)據(jù)庫 ——指的是LuatOS中的FSKV庫，提供鍵值對數(shù)據(jù)庫功能，數(shù)據(jù)持久化在Flash上，使用獨立的KV分區(qū)，使用LuaTools刷機時可選擇清空，默認是不清空。由Flash的特性決定了，寫入次數(shù)是有限的，頻繁寫入導致超限后，將無法設置/更新數(shù)據(jù)，導致系統(tǒng)異常。

為了進一步驗證猜測，讓客戶做了如下測試：

問：“死機重啟后，燒錄不清除KV試試看還會不會重啟，或者去除KV相關操作看還會不會重啟?！?/p>

答：“KV操作挺多的，不好清除，我試下燒錄不清除KV，有時候斷電過一會就好了，不是很好復現(xiàn)，我先試試燒錄不清除KV?！?/p>

客戶反饋：“不清除KV也會有重啟。”

問：“重新燒錄底層的時候，有沒有清理KV。”

答：“有”…

根據(jù)此前客戶反饋和當前測試來看，應該是FALSH模塊有些區(qū)域壞掉了。