《Linuxpstore实现自动抓捕内核崩溃日志.docx》由会员分享，可在线阅读，更多相关《Linuxpstore实现自动抓捕内核崩溃日志.docx（8页珍藏版）》请在三一文库上搜索。
1、简介pstore 文件系统（是的，这是个文件系统）是 Persistent Storage 的缩写，最早在 2010年由Tony Luck设计并合入 Linux主分支，设计的初衷是在内核 Panic/Oops时能自动转存内核日志（log_buf ）,在Panic 重启后，把转存的日志以文件形式呈现到用户空间以分析内核崩溃问题。 这对分析那种小概率且没办法抓到现场的问题非常实用，尤其是现在智能 互联网的设备逐渐普及的时候，远端的设备可以自己捕抓崩溃日志再通过 网络传输到服务器，维护人员就可以根据收集来的日志定位和解决问题， 然后通过OTA让设备升级迭代。根据网上搜寻的资料，在pstore文件系统
2、之前其实有不少类似的实现。? apanicAndroid最早的panic信息记录的方案。在 linux 2.6的安卓的内核中找到，却没有提交到社区，后来被放弃维护了。网上找不到放弃的 原因，我自己猜测是因为其只适用于mtd nand ,然而现在的 Android基本用的都是 emmc apanic应该是 Android Panic 的缩写吧，可以实 现在内核崩溃时，把日志转存到mtd nand。? ramoops这里指的是最早的 ramoops实现，在最新代码已经整合入pstore中，以pstore/ram 的后端形式存在。ramoops可以把日志转存到重启不掉 电的ram中。这里对ram有一
3、点要求，即使重启 ram的数据也不能丢 失。? crashlog这是openwrt提供的内核patch ,并没有提交到内核社区。它也是基于ram,只能转存 Panic/Oops的日志。? mtdoopsMTD?系统支持的功能，与pstore非常相似，只支持转存 Panic/Oops日志，不能以文件呈现，需要用户自行解析整个MT吩区。（因为功能的相似，我实现了mtdpstore 用于替代mtdoops）? kdump如果说pstore是个轻量级的内核崩溃日志转存的方案，kdump则是一个重量级的问题分析工具。在崩溃时，由kdump产生一个用于捕抓当前信息的内核，该内核会U集内存所有信息到dump
4、 core文件中。在重启后，捕抓到的信息保存在特定的文件中。类似的还有 netdump和 diskdump 0 kdump的方案适用于服务器这种有大量资源的设备，功能 也非常强大，但对嵌入式设备非常不友好。pstore经过长期迭代，除了转存 Panic/Oops的日志之外（dmesg前 端）, 还支持 pmsg、console 和 ftrace 的前端，除了 pstore/ram 的后端 之外，还有我设计的pstore/blk 后端，除了支持转存到ram之外，还有block device 和 mtd device 。pstore的前端，是指转存的日志类型，pstore的后端，是指转存到什么类型
5、的设备。目前支持以下几个前端：? dmesg：主要是转存 Panic/Oops时log_buf 里面的内核日志? pmsg：提供给用户空间存储日志的入口，在 Android里有看到被用于 存储系统的日志。? console : 终端日志? ftrace : function trace 的信息目前支持以下几种后端：? pstore/ram : Persistent Ram ,重启不会丢数据的内存? pstore/blk : （ v5.8以后的版本）所有可写的块设备，例如磁盘、U盘、emmc NFTL nand 等? mtd device : （ v5.8 以后的版本） mtd 设备，例如 mt
6、d nand 。 （ mtd 设备的支持依赖于pstore/blk 后端，准确来说不是一种独立后端）怎么用就像把大象装入冰箱只需要打开冰箱，把大象放进去，关上冰箱门的3个步骤，使用 pstore也只需要3个步骤：1 .使能 pstore2 .挂载 pstore文件系统3 .读取转存的日志文件详细的说明可以看源码上的文档，本文只做基本功能的介绍。? Documentation/admin-guide/ramoops.rst? Documentation/admin-guide/pstore-blk.rst使能在menuconfig 中选择内核 pstore 模块$ make menuconfig
7、| - File systems- Miscellaneous filesystems| - Persistent store support|- Log kernel console messagesI，Log user messages # pmsg 前端- Persistent function tracer- Log panlc/oops to a RAM buffer # pstore/ram 后揣|- Log panlc/oops to a block device 一 一 一 ：三:上述两个后端 2选1即可，前端就根据自己的需求选择，至于 dmesg前端，默认使能没得选。如果希望
8、用在mtd设备上，还需要选择mtdpstore 模块：$ make menuconfig-5 Device DriversI-A Memory Technology Device (MTD) support |- Lag panic/oops to an MID buffer based on pstore选上就可以用了？虽然我非常想说“是的”，但事实却有点“骨感”。即使所有前端都使用默认配置，pstore/ram 至少也需要知道可用的内存范围吧？ pstore/blk至少也需要知道使用哪个块设备吧？pstore/ram 支持模块参数(cmdline)、设备树、和 Platform Data
9、的 3种配置方式，从代码来看，优先级关系是：模块参数 PlatformData 设备树。pstore/blk 支持 Kconfig 和 模块参数(cmdline) 的两种配置方式， 且模块参数比 Kconfig有更高的优先级。pstore/ram 我接触也不多，直接介绍pstore/blk的使用方法。对新同学来说，请忽略一大堆乱七八糟的属性配置(使用默认值)，只需要告 诉pstore/blk后端使用哪个块设备即可。在Kconfig 中配置：$ make menuconfig|- File systems- Miscellaneous filesystems- Persistent store
10、support | - Log panic/oops to a block device, 1| - () block device identifier # 使用哪个块设备？如果使用cmdline ,可以这么写：pstore_blk.blkdev=XXXX或者以模块加载：$ sudo insmod pstore_blk.ko blkdev=XXX这里的块设备可以是正表整个磁盘的sda,也可以是代表某个分区的mmcblk0p4。虽然支持7种变体，但常用的还是两种：? /dev/: 例如，使用 U盘的第2个分区，则是/dev/sdb2? : :例如，mmdS备第 6 个分区，则是 179:6形式
11、大概是这样：$ sudo insmod pstore_blk.ko blkdev=/dev/sdb2或者$ cat /proc/cmdline. pstore_blk.blkdev=179:6 .如果是mtd设备，可以直接指定mtd分区名或者编号，例如：pstore_blk.blkdev=pstore # 假设存在名为 pstore 的 MT防区OK对新同学来说，到这里配置就够了。可以从我的 github(见参考链接 2)上看到我之前是怎么测试的。如果需要知道每个配置项的作用，还是 看内核文档吧(ramoops.rst 或 pstore_blk.rst ),或者在 Kconfig 中 按h显示
12、相关配置项的说明。挂载在使能且正确配置设备后，启动的时候应该会有这样的日志：pstore_zone: registered pstore_blk as backend for kmsg(Oops,panic_write) pstore: Registered pstore_blk as persistent store backend这代表pstore找到了设备且正常注册。接下来，我们还需要通过挂 载的形式触发pstore从设备读取数据。常见的挂载是这样的： mount -t pstore pstore /sys/fs/pstore 挂载后，通过 mount能看到类似这样的信息：# mount
13、 .pstore on /sys/fs/pstore type pstore (rw,relatime).如果曾经触发过崩溃日志，在挂载点应该有类似这样的文件：# ll /sys/fs/pstore.-r-r-r-1 root root15521 Jan 1 00:06 dmesg-pstore_blk-0 .如果需要验证，咱们可以这样主动触发内核崩溃：# echo c /proc/sysrq-trigger我是在 U 盘、SD卡、 mmc nand 上验证的， maintainer Kees Cook 提供了另外一种基于loop的验证方法，实现用文件模拟块设备。当然这 方法不适用于转存Pan
14、ic日志，只能用于 Oops或者其他前端：# insmod pstore.ko compress=off # insmod pstore_zone.ko# truncate pstore-blk.raw -size 100M# losetup -f -show pstore-blk.raw /dev/loop0# insmod pstore_blk.ko blkdev=/dev/loop0 kmsg_size=16 console_size=64 best_effort=on读取经过上述的挂载后，可以在挂载点看到转存的日志文件。既然是文 件，肯定支持文件的一系列操作，例如读取、删除。#1 Pa
15、rt1rootTinaLinux:/sys/fs/pstore # head -n 10 dmesg-pstore_blk-1 Oops: Total 2 timesOops 2.743794 Bluetooth: RFCOMM socket layer initialized2.743813 Bluetooth: RFCOMM ver 1.112.743822 8021q: 802.1Q VLAN Support v1.82.751766 reg-virt-consumer reg-virt-consumer.1: Failed to obtain supply drivevbus: -51
16、72.752330 reg-virt-consumer reg-virt-consumer.1: Failed to obtainsupply drivevbus: -5172.752742 ubi0: attaching mtd42.890302 random: crng init done2.965927 ubi0: scanning is finishedrootTinaLinux:/sys/fs/pstore # lldrwxr-x- drwxr-xr-x-r-r-r-pstore_blk-0-r-r-r-pstore_blk-12 root5 root rootrootroot ro
17、ot0 Jan0 Jan15521 Jan 11 00:11 .1 00:11 .00:06 dmesg-rootroot15128 Jan 100:11 dmesg-rootTinaLinux:/sys/fs/pstore # rm dmesg-pstore_blk-1 rootTinaLinux:/sys/fs/pstore # lldrwxr-x- drwxr-xr-x-r-r-r-pstore_blk-02 root5 root rootrootroot root0 Jan0 Jan15521 Jan 11 00:13 .1 00:11 .00:06 dmesg-对dmesg前端的息。
18、例如：Oops: Total 2 times启动以来第2次触发Oops#1 Part1志。Panic/Oops日志，pstore会自动添加两行统计信#表示触发了 Oops,且是自系统安装后第一次Oops。#表示这是上一次运行期间第1次触发Oops的日可以发现，第一行是累计总的触发次数，第二行是上一次启动触发的 次数。每个文件名的格式都是- ,例如dmesg-pstore_blk-1 表示dmesg前端,pstore_blk后端以及是 dmesg前端白第 1个zone的日志。当然，除了 dmesg前端外,其他前端的名字大概是这样的：# ll-r-r-r-r-r-r-r-r-r-r-r-r1111
19、root root31 1月root root3666 1月root root 65524 1 月root root9 1月15 11:53 console-pstore-blk-015 11:53 demsg-pstore-blk-015 11:53 ftrace-pstore-blk-015 11:53 pmsg-pstore-blk-0除此之外，每个文件的时间戳表示崩溃触发的时间。上例中，由于系统并没有实现同步更新系统时间，所以时间戳不合理。展望未来正如我前文说的，pstore在物联网设备逐渐普及的现在，能发挥很大 的作用，例如智能音箱和扫地机已经用起来了。全功能支持到目前为止，不管是块
20、设备还是mtd设备，社区的代码都没能做到pstore的全部前端的支持。设备dmesg(Oops)dmesg(Panic)pmsgconsoleftrace块设备YNYYYMTDK 备YYNNNram设备YYYYY块设备如果需要记录Panic日志，需要提供一个在Panic时写块设备的接口。我在全志的mmcffi nand驱动中实现了这样的接口，却因为种种原因不适合提交到社区。社区块驱动的适配寄希望于更多同学的努力了。MTD备很早前就有了panic_write()的定义，因此可以支持 Panic日志转存。不支持其他前端，则是因为其擦写的物理特性。对pmsg,console , ftrace 等这些
21、不能页对齐写入的前端，还需要更多的适配工 作。迁移 pstore/ram在当前pstore的目录结构是这样的：$ tree fs/pstorefs/pstore/I blk.c# pstore/blk 后端的实现I ftrace.c# ftrace 前端的实现I inode.c # pstore文件系统的注册与操作| internal.hI KconfigI MakefileI platform.c# pstore前后端功能的核心I pmsg.c # pmsg 前端的实现I ram.c # pstore/ram 后端的实现I ram_core.c# pstore/ram 后端的实现1 zone.c # pstore/zone实现存储空间的分配和管理在我的补丁之前，只支持转存日志到ram,因此如果研读代码，我们会发现ram.c和ram_core.c 实现了两部分功能：1. dram空间分配与管理2. dram的读写操作我实现的blk.c支持了转存到块设备。但是后来发现不管pstore/ram还是pstore/blk ,他们对于存储空间的分配和管理极度相似，我就提炼出 了 pstore/zone 。于是乎，期望的代码层次应该是这样的：pstore/ram 要整合入 pstore/zone 已经与maintainer达成共识，但还需要更多同学一同努力做更多兼容，例如ecc的支持