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

隔著屏幕都感覺(jué)到了客戶(hù)的著急和無(wú)奈，我決定和這位用戶(hù)一起揪出這個(gè)“搗蛋鬼”。

?

一、查找線(xiàn)索

按常規(guī)流程先詢(xún)問(wèn)用戶(hù)開(kāi)發(fā)模塊、開(kāi)發(fā)方式，并要求提供對(duì)應(yīng)日志。經(jīng)確認(rèn)如下：

開(kāi)發(fā)模塊：Air780E

最新資料：www.air780e.cn

開(kāi)發(fā)方式：LuatOS

開(kāi)發(fā)教程：

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

客戶(hù)提供日志反饋：

腳本日志沒(méi)報(bào)錯(cuò)誤，就是不定時(shí)卡住一會(huì)，然后就重啟了。

?

第一反應(yīng)：不會(huì)是死循環(huán)導(dǎo)致的重啟吧？

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

看來(lái)不是死循環(huán)導(dǎo)致的看門(mén)狗重啟問(wèn)題。

為了進(jìn)行一步排查重啟原因，我讓用戶(hù)用pm.lastReson()這個(gè)接口打印開(kāi)機(jī)原因值。

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

根據(jù)接口文檔相關(guān)說(shuō)明來(lái)看，確實(shí)不是內(nèi)部看門(mén)狗導(dǎo)致的重啟，是異常重啟導(dǎo)致的。

接口文檔詳見(jiàn)：

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

?

二、了解背景

心想看不出啥具體原因，先了解一下客戶(hù)使用背景吧，說(shuō)不定會(huì)有啥線(xiàn)索。

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

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

我又問(wèn)：“換DEMO會(huì)重啟嗎？ 確認(rèn)一下是硬件問(wèn)題，還是軟件問(wèn)題。 ”

客戶(hù)反饋：“ 今天測(cè)試過(guò)，只下載腳本是一定會(huì)出問(wèn)題。 然后我剛剛重新下載底層和腳本，目前五分鐘沒(méi)有重啟。”

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

客戶(hù)反饋：“我們是因?yàn)橛幸粋€(gè)設(shè)備到客戶(hù)手上有這個(gè)問(wèn)題是V1108的，然后老化區(qū)只有這個(gè)設(shè)備也是異常重啟，是V1106的，然后就看的這個(gè)，后面重新燒錄1106的底層也是正常的，這設(shè)備挺難出現(xiàn)這個(gè)問(wèn)題的，只能我們這邊掛著測(cè)一下。”

看來(lái)又是一個(gè)令人頭大的重啟問(wèn)題，要等客戶(hù)提供底層日志來(lái)進(jìn)一步排除問(wèn)題了。

三、重要線(xiàn)索

客戶(hù)把掛測(cè)的底層日志提供過(guò)來(lái)了，打開(kāi)后確實(shí)看到了RamDumpData開(kāi)頭的死機(jī)信息。

?

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

?

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

客戶(hù)回答，確實(shí)有KV的操作。

本文提到的KV：

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

為了進(jìn)一步驗(yàn)證猜測(cè)，讓客戶(hù)做了如下測(cè)試：

問(wèn)：“死機(jī)重啟后，燒錄不清除KV試試看還會(huì)不會(huì)重啟，或者去除KV相關(guān)操作看還會(huì)不會(huì)重啟?！?/p>

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

客戶(hù)反饋：“不清除KV也會(huì)有重啟?！?/p>

問(wèn)：“重新燒錄底層的時(shí)候，有沒(méi)有清理KV。”

答：“有”…

根據(jù)此前客戶(hù)反饋和當(dāng)前測(cè)試來(lái)看，應(yīng)該是FALSH模塊有些區(qū)域壞掉了。

四、確認(rèn)猜測(cè)

至此，可以說(shuō)這個(gè)重啟的原因基本是確認(rèn)了，導(dǎo)致模塊令人琢磨不透的重啟問(wèn)題的“搗蛋鬼”也基礎(chǔ)上算是給揪出來(lái)了。但是，還是需做進(jìn)一步的測(cè)試來(lái)確定猜測(cè)。

研發(fā)大佬給了一下測(cè)試固件，來(lái)確認(rèn)猜測(cè)是否正確。

?

經(jīng)過(guò)測(cè)試驗(yàn)證后，確定是FALSH部分區(qū)域壞掉引起的重啟。

至此這個(gè)“重啟案件”算是偵破了。

給客戶(hù)的建議：

要改腳本，需要大幅度減少寫(xiě)KV的次數(shù)，防止破壞模塊重啟的“搗蛋鬼”再次出來(lái)?yè)v亂。

溫馨提示：

KV的寫(xiě)壽命是10萬(wàn)次，過(guò)于頻繁操作可能會(huì)導(dǎo)致FLASH壞掉，引起設(shè)備反復(fù)重啟。

因此，在寫(xiě)代碼的時(shí)候要盡量減少寫(xiě)KV的次數(shù)。

審核編輯 黃宇