令人头疼的异常重启，竟然是KV的锅…

​在技术支持群，看到有用户报了一个不明原因的重启问题。 重启现象是 ——有极个别设备在工作中不定时反复异常重启，大部分设备正常；反复重启设备，有时候又能持续正常工作。

隔着屏幕都感觉到了客户的着急和无奈，我决定和这位用户一起揪出这个“捣蛋鬼”。

​

一、查找线索

按常规流程先询问用户开发模块、开发方式，并要求提供对应日志。经确认如下：

开发模块：Air780E

最新资料：www.air780e.cn

开发方式：LuatOS

开发教程：

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

客户提供日志反馈：

脚本日志没报错误，就是不定时卡住一会，然后就重启了。

​

第一反应：不会是死循环导致的重启吧？

用户反馈：“没有死循环，任务里面都有延时的，而且大部分设备是正常的。且重启的时间也不定，最短4秒，最长是三分多钟，看起来不符合20秒的看门狗重启呀，而且设备昨天有正常工作一天，然后异常的时候就持续一直异常。但是这个固件的绝大部分设备是正常工作，不会异常重启的。”

看来不是死循环导致的看门狗重启问题。

为了进行一步排查重启原因，我让用户用pm.lastReson()这个接口打印开机原因值。

客户反馈：“我们有平台上传数据， pm.lastReson()是006异常重启 ”。

根据接口文档相关说明来看，确实不是内部看门狗导致的重启，是异常重启导致的。

接口文档详见：

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

​

二、了解背景

心想看不出啥具体原因，先了解一下客户使用背景吧，说不定会有啥线索。

我问：“之前正常，现在是用不了，一直在重启吗？”

客户反馈：“也不是吧，一开始是好的，然后挂了几个月一直重启，最近发现，昨天我拿过来挂了一天又正常，然后今天又重启，老化区就这个设备会重启，其他同固件是正常的。”

我又问：“换DEMO会重启吗？ 确认一下是硬件问题，还是软件问题。 ”

客户反馈：“ 今天测试过，只下载脚本是一定会出问题。 然后我刚刚重新下载底层和脚本，目前五分钟没有重启。”

看上去应该不是硬件问题，可能是软件引起的。心想让客户用最新版本试一下吧，确认一下还会不会出现问题。

客户反馈：“我们是因为有一个设备到客户手上有这个问题是V1108的，然后老化区只有这个设备也是异常重启，是V1106的，然后就看的这个，后面重新烧录1106的底层也是正常的，这设备挺难出现这个问题的，只能我们这边挂着测一下。”

看来又是一个令人头大的重启问题，要等客户提供底层日志来进一步排除问题了。

三、重要线索

---

客户把挂测的底层日志提供过来了，打开后确实看到了RamDumpData开头的死机信息。

​

打开上面的RamDumpData出现如下信息：

​

我赶紧和研发大佬确认，可能是啥情况。大佬问答大概率是FLASH坏掉了，让和客户确认不是有KV相关的操作。

客户回答，确实有KV的操作。

本文提到的KV：

KV数据库 ——指的是LuatOS中的FSKV库，提供键值对数据库功能，数据持久化在Flash上，使用独立的KV分区，使用LuaTools刷机时可选择清空，默认是不清空。由Flash的特性决定了，写入次数是有限的，频繁写入导致超限后，将无法设置/更新数据，导致系统异常。

为了进一步验证猜测，让客户做了如下测试：

问：“死机重启后，烧录不清除KV试试看还会不会重启，或者去除KV相关操作看还会不会重启。”

答：“KV操作挺多的，不好清除，我试下烧录不清除KV，有时候断电过一会就好了，不是很好复现，我先试试烧录不清除KV。”

客户反馈：“不清除KV也会有重启。”

问：“重新烧录底层的时候，有没有清理KV。”

答：“有”…

根据此前客户反馈和当前测试来看，应该是FALSH模块有些区域坏掉了。

四、确认猜测

---

至此，可以说这个重启的原因基本是确认了，导致模块令人琢磨不透的重启问题的“捣蛋鬼”也基础上算是给揪出来了。但是，还是需做进一步的测试来确定猜测。

研发大佬给了一下测试固件，来确认猜测是否正确。

​

经过测试验证后，确定是FALSH部分区域坏掉引起的重启。

至此这个“重启案件”算是侦破了。

给客户的建议：

要改脚本，需要大幅度减少写KV的次数，防止破坏模块重启的“捣蛋鬼”再次出来捣乱。

温馨提示：

KV的写寿命是10万次，过于频繁操作可能会导致FLASH坏掉，引起设备反复重启。

因此，在写代码的时候要尽量减少写KV的次数。

审核编辑 黄宇