Lin系统异常重启分析
LIN总线系统的故障案例分析
2．大众高尔夫空调故障 （1）故障现象
一辆高尔夫A7轿车，采用半自动 空调系统，车主反映空调开启后压缩 机及鼓风机不工作，但空调控制面板 上的A/C按键指示灯常亮。
（2）故障诊断
维修前，技师先分析高尔夫A7轿车的空调控制系统采用LIN总线
通讯系统结构，如图所示。
J533-网关
J301-空调控制单元
初步诊断为该段线路中的LIN总线出现问题，使用示波器检测该处线路
的波形，发现电压始终为0V，即此处的LIN总线连接中存在对地短路
的故障。
表
高尔夫A7空调控制单元故障状态下的数据流
检测项目 压缩机关闭条件 压缩机电路，实际值（无显示）
测量值 制冷剂压力传感器故障 0.0A
压缩机电流，规定值（无显示） 0.0A
能够正确认识 LIN总线系统的故障
案例分析
LIN总线系统的故障案例分析
对于汽车LIN总线故障的诊断维 修，主要结合故障现象通过自诊断及 专用的检测仪进行检测，然后通过人 工经验和自诊断结果来排查故障。
1．大众捷达车窗主控开关故障 （1）故障现象
一辆2006年款的 捷达轿车，行驶里程4 万公里，车主反映驾 驶侧的主控开关无法 升降右后侧的车窗。
压缩机电流，规定值（无显示） 0.555A
Байду номын сангаас
制冷剂压力（无显示）
12.6bar
鼓风机状态（无显示）
激活
感 谢 聆听
J126-鼓风机控制单元
G805-高压压力传感器
N280-空调压缩机调节阀
V2-鼓风机电机
其中空调控制单元J301通过LIN总线将开关信号发送至高压压力传感 器G805及鼓风机控制单元J126上
并通过电信号控制调整高压压力传感器G805及鼓风机控制单元J126的 工作状态
卡罗拉lin总线系统故障维修
卡罗拉LIN总线系统故障维修1. 故障排除流程对于卡罗拉LIN总线故障，可以按下面的流程图（图2-3-26）进行故障排除。
根据故障症状表进行排除图2-3-26卡罗拉LIN总线故障排除流程图2．.ECU端子的检查（1）检查主车身ECU(仪表板接线盒)【不带智能上车和启动系统，不带自动灯控】，如图2-3-27、图2-3-28所示。
①断开课代表板接线盒连接器2B、2F和2G。
图2-3-27 车身主ECU（前侧）图2-3-28主车身|ECU（后侧）②测量线束侧连接器和车身搭铁之间的电压和电阻，如表2-3-2所示。
表2-3-2注：如不符合规定，则线束侧可能在故障。
③重新连接仪表板接线盒连接器2B、2E、2F和2G.④根据表2-3-3中的值测量脉冲。
表2-3-3提示：如果结果不符合规定，，则主车身ECU（仪表板接线盒总成）可能有故障。
(2)检查电动车窗升降器电动机总成（驾驶员侧）；①断开电动机连接器16．如图2-3-29所示。
图2-3-29电动机连接器②根据表表2-3-4中的值测量电压和电阻。
表2-3-4提示：如果结果不符合规定，则线束侧可能有故障。
③重新连接电动机连接器I6。
④根据表2-3-5中的值测量脉冲。
表2-3-5提示：如果结果不符合规定，电动机可能有故障。
(3)检查滑动天窗ECU(带滑动车窗).①断开ECU连接器09，如图2-3-30所示。
图2-3-30 ECU连接器09 ②根据表2-3-6中的值测量电压和电阻。
表2-3-6提示：如果结果不符合规定，则线束侧可能有故障。
③重新连接ECU连接嚣09。
④根据表2-3-7中的值测量脉冲。
表2-3-7提示：如果结果不符合规定，ECU 可能有故障(4)检查认证ECU（带智能上车和启动系统）．①断开ECU连接器E36．如图2-3-31所示。
图2-3-31 ECU连接器E36 ②根据表2-3-8中的值测量电压和电阻。
表2-3-8提示：如果结果不符合规定，则线束侧可能有故障。
矿机重启原因分析报告
矿机重启原因分析报告
矿机重启是指矿机设备出现故障或异常情况，导致系统自动重启以修复问题或恢复正常运行的过程。
矿机重启的原因一般可以分为硬件问题和软件问题两个方面。
首先，硬件问题是指矿机出现了硬件故障或异常。
比如，矿机主板或电源出现了电路短路、过载或电压异常等问题，导致系统崩溃或自动重启。
此外，矿机的散热系统可能存在问题，导致温度过高而触发重启保护机制。
此外，矿机的风扇可能也出现了损坏或堵塞，导致散热不良，进而引发重启。
另外，矿机的硬盘可能存在损坏、读写错误等问题，导致系统无法正常引导，需要重启。
其次，软件问题也是矿机重启的常见原因。
例如，矿机操作系统出现了崩溃、冲突或错误，导致系统无法正常运行，需要重启来恢复。
此外，矿机的驱动程序可能存在问题，导致设备无法正常工作，需要重启更新或修复驱动。
另外，矿机的挖矿软件可能存在兼容性问题或者配置错误，导致系统崩溃或无法工作，需要重启来修复。
总体而言，矿机重启的原因主要源于硬件故障或异常以及软件问题。
针对不同的原因，可以采取相应的措施来解决问题。
对于硬件问题，需要检查并修复矿机的电路、电源、散热系统、风扇和硬盘等部件。
对于软件问题，需要更新操作系统、驱动程序和挖矿软件，甚至可能需要重新配置挖矿软件的参数。
总之，及时分析矿机重启的原因，并采取相应的措施来解决问题，可以提高矿机的稳定性和效率，使其能够持续稳定地进行挖矿操作。
汽车LIN总线系统故障诊断
图２ ＬＩＮ总线系统检 测流 程 说 明１：正 常波 形说 明Ｊ３８６至 测试 点之 间通讯 正常 ： 说 明２：存 在 两 种可 能 ：①测 量 点 前存 在 断 路 故 障 ， ｌ２Ｖ 波 为隐 性修眠 电压 ：，ＬＩＮ系统 存在对 正极 短路 故障 ； 说 明３：断 开Ｊ９２６后 仍 为 １２Ｖ平波 ，说 明ｌ２Ｖ电压 由测 试 点 前 ＬＩＮ线线 路或 Ｊ３８６存 在对 正极 短路造 成 ； 下步测 量需 断开Ｊ３８６ ＬｊＬＩＮ 线连 接 ； 说 明４：０Ｖ平波 说 明ＬＩＮ系统 存在 对地 短路 故障 ； 说 明５：测 量时 保持Ｊ３８６与ＬＩＮ线 连接 ； 说 明６： 下步测 量断 开Ｊ３８６与 Ｌ１Ｎ线连 接 ； 说 明７： 正常波 形说 明测 量 点前 正常 ，故障 由Ｊ９２６造 成 。
迈腾 １．８ＴＳＩ２０１２款 舒适 总线 系统 结构 如 图ｌ所示 。Ｊ３８６接 收到 的 闭锁 开 关和 玻璃 升 降主 开关 所 发 出的控 制信 号 ， 以及 Ｊ３９３接 收 到的 遥控 钥 匙 发 出的 闭锁 和玻 璃 升 降信 号 ，最终 需 通过 ＬＩＮ总线 传输 至 Ｊ９２６和Ｊ９２７。Ｊ９２６和Ｊ９２７接 收 到控 制 信号 以后 ，控 制 闭锁 电机或 玻 璃 升降 电机 执行 相关动 作 。
２ ＬＩＮ总 线 系 统
２．１ ＬＩＮ总线 系统特 点 ＬＩＮ采 川 单 主／多从 带 信 息 标 识 的广 播 式 信 息 传播 方 式 ，网 络
节 点根 据 在通 信 中得 地位 分 为主 节 点和从 节 点 。ＬＩＮ总线 的 传输 速 率可 达 ２０ｋｂｐｓ，通 常一 个ＬＩＮ网络 节 点 数 目小 于 １２个 ， ６４个 标 识 符 。ＬＩＮ系统 支持 休眠 工作 模式 ，此 时总 线上 为 １２Ｖ隐形 电压 ｝】］。 ２．２ ＬＩＮ总线 系统结 构
学习情境四 LIN总线系统工作异常的故障检修
（3）LIN主单元故障的排除方法
诊故障码表
当主车身ECU和认证ECU之间存在断 路、短路或ECU通信故障时，会输出DTC 码 B2287，其故障部位主要在于认证ECU、 主车身ECU、线束或连接器。相关电路如 图4-30所示。
图4-30
注意：点火开关置于OFF位置，使用智能检测仪进行故障排除时，将智能检 测仪连接至车辆，以1.5秒钟的间隔打开和关闭门控灯开关，直到检测仪和车辆 之间开始通信。
7.LIN总线数据传输的顺序
（1）LIN 主控制单元的软件内已设定了一个顺序，LIN主控制单元就按这个
顺序将信息标题发送至LIN总线上
（2）常用的信息会多次传递。
（3） LIN主控制单元的环境条件可能会改变信息的顺序。如：点火开关接
通/关闭；自诊断已激活/未激活；停车灯接通/关闭。
三、LIN总线在实车上的应用
注意：收发器的型号 不同，显性平有差异
隐性电平：如果无信息发送到LIN数据总线上（总线空闲）或者发送到LIN数据总线上 的是一个隐性位 显性电平：当传输显性位时，发送控制单元内的收发器将LIN数据总线接地。
（2）信号传递的安全性
发送信号电压必须满足隐性电平大于电源电压的80% 接收信号电压必须满足隐性电平大于电源电压的60%
当VBAT为低时（本地节点断电或断路等）防止LIN 总线驱动节点的电源线，从而大大增加总线负载
（1）受标识符长度的限制
（2）受总线物理特性的限制——节点数越多网络 阻抗越低（并联），会发生通信故障。LIN系统每 增加一个节点大约使网络阻抗降低3％。
3.LIN总线的信号
（1）信号波形
显性电平— 接近于0V 隐性电 平—12V
④这种通信方法速度缓慢，LIN节点很难及时地接收和处理数据，并选择性地 将它传输给其他节点。
一次AirNet自动化系统席位重启异常的分析与思考
一次 AirNet自动化系统席位重启异常的分析与思考摘要：目前空管自动化系统的维护主要包含日维护、月维护、季度维护、年度维护等定期维护内容，其中月维护的主要内容为席位的操作系统级别的重启与重置，目的为释放该席位主机的系统内存、进行预防性重启以期望提前发现系统级别的异常或者硬件故障等。
本文阐述了一次月维护过程中，系统无法正常启动到正常AirNet自动化系统的软件界面，并通过分析与思考日常定期维护中遇到的典型异常，为自动化月维护中再次出现类似的异常提供参考。
关键词：空管自动化；定期维护；异常原因；分析与处理1.引言随着中国民航的快速发展，航班飞行流量快速的增长，各地空管单位都建立起多套空管自动化系统[1]，其中就有不少现场建立了AirNet空管自动化系统。
根据上级、民航空管各类维护规程、标准等参考性文件要求，自动化系统定期维护中，现阶段主要包含日维护、月维护、季度维护、年度维护等定期维护内容。
这些定期维护都具有各自的维护目标与希望达到的目的，其中月维护的其中一个维护目标为定期发现系统设备潜在的软件异常或者硬件隐患。
对于在月维护过程中的操作系统级别的重启过程中，发现的多种异常现象，大多由于空管自动化应用软件运行的操作系统，例如RedHat或者其他类Unix系统本身的系统设置或者依赖软件、驱动程序等方面的问题引起的，也有部分为空管自动化应用软件的Bug 引起的系统问题，例如应用软件定期释放操作系统资源不及时，如不及时内存释放或者随着运行时间的积累占用系统资源过多。
因此，定期月维护中重启席位主机的操作系统有利于提前发现系统设备潜在的软件异常或者硬件隐患，该项定期操作在空管自动化的维护中起着十分重要的作用。
本文结合实际工作中的一个典型案例，阐明AirNet自动化系统席位操作系统重启中异常的分析与排除思路。
1.重启异常的分析与处理2.1案例具体情况异常的具体情况：UTC时间2019年3月23日15时30分，技术人员反映在对AirNet自动化系统中sdd22席位主机RedHat 5.8操作系统进行例行重启的过程中，该席位启动到命令行界面，未能正常启动到应用软件的正常界面。
任务1 LIN总线系统检修(最新模板)
故障诊断与排除
• 首先调整起动机电磁开关的闭合时间，将调整螺钉适当旋入。若仍然存在齿 响，再检查驱动齿轮与飞轮齿环的磨损情况。若齿磨损大于3mm，应焊修或更 换。
汽车电气设备检修
驱动齿轮与飞轮齿环不能啮合且有撞击声
故障现象
• 接通点火开关，启动起动机时，伴有连续不断的齿轮撞击声，使驱动齿轮不 能与飞轮齿环啮合。
故障原因
(1)主回路通电过早。在驱动齿轮与飞轮齿环还未啮合之前，驱动齿轮就已转 动。 • (2)起动机安装螺栓松动。 • (3)驱动齿轮和飞轮齿环的齿损害或磨损严重，齿长不足，啮合不牢，扭矩过 大时，两齿轮打滑。 •
汽车电气设备检修
二、LIN总线含义
CAN与LIN关系图
汽车电气设备检修
二、LIN总线含义
LIN总线是CAN总线的子网，连接在CAN总线上的控制单元执行局域互联 网(LIN)的主功能。所连接的局域互联网(LIN)副控制单元的诊断通过局域互 联网(LIN)主控制单元进行，如图所示。
HN主、副控制单元的关系图 HN主
linux常见故障排错思路
Linux常见故障排错思路Linux操作系统因其开源、稳定、安全等特点，在服务器领域得到广泛应用。
但在使用过程中，无论是初学者还是经验丰富的系统管理员，都可能会遇到各种问题。
本文将详细阐述Linux系统中常见的故障及其排错思路，旨在帮助读者快速定位并解决问题。
一、启动故障1. GRUB引导加载器问题- 故障现象：系统启动时，无法加载GRUB或出现GRUB错误提示。
- 排错思路：- 检查GRUB配置文件是否正确。
- 使用Live CD/USB启动，进入救援模式修复GRUB。
- 重新安装GRUB到MBR。
2. 内核问题- 故障现象：启动过程中内核崩溃或无法继续启动。
- 排错思路：- 查看启动日志，分析内核报错信息。
- 尝试更换不同版本的内核启动。
- 检查硬件兼容性，如内存、CPU等。
3. 文件系统损坏- 故障现象：系统提示文件系统损坏，无法正常挂载。
- 排错思路：- 使用fsck工具检查和修复文件系统。
- 分析dmesg输出，查找与文件系统相关的错误。
- 在必要时恢复备份数据。
二、网络故障1. 无法连接到网络- 故障现象：系统无法访问外部网络或局域网。
- 排错思路：- 检查网络接口是否启动。
- 使用ping命令测试网络连通性。
- 查看/etc/resolv.conf文件中的DNS设置。
- 检查防火墙和网络策略配置。
2. SSH连接问题- 故障现象：无法通过SSH远程连接到服务器。
- 排错思路：- 检查SSH服务是否运行。
- 查看SSH配置文件（如/etc/ssh/sshd_config）是否正确。
- 使用netstat或ss命令检查SSH端口监听状态。
- 查看系统日志（如/var/log/auth.log）中的SSH相关记录。
三、性能问题1. 系统负载过高- 故障现象：系统响应缓慢，CPU、内存或磁盘负载过高。
- 排错思路：- 使用top、htop或vmstat命令监控系统资源使用情况。
- 分析系统日志，查找可能导致高负载的原因。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Lin系统异常重启分析st reboot 这个命令是查看每次系统重启的信息[root@dg01 log]# last rebootreboot system boot 2.6.32-300.10.1.Thu May2922:48 (00:23)reboot system boot 2.6.32-300.10.1.Thu May2922:08 (00:38)。
其中最近的一次重启时间是May2922:48，距离当前时间已经运行了23分钟了，而倒数第二次重启时间是May2922:08，运行了38分钟2.Uptime[root@dg01 ~]# uptime23:44:20 up 56 min, 2 users, load average: 0.04, 0.01, 0.00Uptime显示了系统当前时间23:44:20，运行时间56 min，当前用户连接数为2，系统的负载。
3.[root@dg01 ~]# w23:46:21 up 58 min, 2 users, load average: 0.00, 0.00, 0.00USER TTY FROM LOGIN@ IDLE JCPU PCPU WHATroot pts/1192.168.56.10122:5412:250.04s0.04s -bashroot pts/2192.168.56.10123:330.00s0.13s0.00s ww比uptime显示的信息更加丰富了，除了显示了uptime的信息外，还显示了下列的信息：user：显示登录的用户账号TTY：用户登录所用的终端FROM：显示用户在何处登录系统，这里显示的是IP：192.168.56.101，正是小鱼自己本地IP地址Login@：显示何时登录系统IDLE：表示用户空闲时间，从用户上一次任何结束后开始计时JCPU : 终端代号来区分，表示在摸段时间内，所有与该终端相关的进程所消耗的cpu时间PCPU：指what域的任务执行后消耗的cpu时间What：表示当前执行的任务4.Who[root@dg01 ~]# whoroot pts/12014-05-2922:54 (192.168.56.101)root pts/22014-05-2923:33 (192.168.56.101)who显示登录系统的用户，输出的信息没有w全5.我们来看看系统重启、关闭对应系统的后台日志输出信息正常reboot时系统日志信息如下：[root@dg01 log]# reboot[root@dg01 log]# less messages。
May2922:47:08 dg01 shutdown[3829]: shutting down for system rebootMay2922:47:09 dg01 smartd[3370]: smartd received signal 15: TerminatedMay2922:47:09 dg01 smartd[3370]: smartd is exiting (exit status 0)May2922:47:09 dg01 avahi-daemon[3298]: Got SIGTERM, quitting.May2922:47:09 dg01 avahi-daemon[3298]: Leaving mDNS multicast group on interfac e bond0.IPv6with address fe80::a00:27ff:fea5:4e59.May2922:47:09 dg01 avahi-daemon[3298]: Leaving mDNS multicast group on interfac e bond0.IPv4with address 192.168.56.110.May2922:47:11 dg01 xinetd[2957]: Exiting...May2922:47:15 dg01 hcid[2721]: Got disconnected from the system message bus May2922:47:15 dg01 multipathd: mpath1: stop event checker thread (1086806336) May2922:47:15 dg01 multipathd: --------shut down-------May2922:47:16 dg01 auditd[2538]: The audit daemon is exiting.May2922:47:16 dg01 kernel: type=1305 audit(1401418036.445:75): audit_pid=0 old=25 38 auid=4294967295 ses=4294967295 res=1May2922:47:16 dg01 pcscd: pcscdaemon.c:572:signal_trap() Preparing for suicide May2922:47:17 dg01 pcscd: hotplug_libusb.c:376:HPRescanUsbBus() Hotplug stoppe dMay2922:47:17 dg01 pcscd: readerfactory.c:1379:RFCleanupReaders() entering clean ing functionMay2922:47:17 dg01 pcscd: pcscdaemon.c:532:at_exit() cleaning /var/runMay2922:47:17 dg01 kernel: Kernel logging (proc) stopped.May2922:47:17 dg01 kernel: Kernel log daemon terminating.May2922:47:18 dg01 exiting on signal 15--上面这部分是关于系统正常关闭的日志，看见有个很清晰的May2922:47:08 dg01 shut down[3829]: shutting down for system rebootMay2922:48:34 dg01 syslogd 1.4.1: restart.May2922:48:34 dg01 kernel: klogd 1.4.1, log source = /proc/kmsg started.May2922:48:34 dg01 kernel: Initializing cgroup subsys cpusetMay2922:48:34 dg01 kernel: Initializing cgroup subsys cpuMay2922:48:34 dg01 kernel: Linux version 2.6.32-300.10.1.el5uek (mockbuild@ca-buil ) (gcc version 4.1.220080704(Red Hat4.1.2-50)) #1 SMP Wed Feb 22 17:37:40 EST 2012May2922:48:34 dg01 kernel: Command line: ro root=LABEL=/ rhgb quietMay2922:48:34 dg01 kernel: KERNEL supported cpus:May2922:48:34 dg01 kernel: Intel GenuineIntelMay2922:48:34 dg01 kernel: AMD AuthenticAMDMay2922:48:34 dg01 kernel: Centaur CentaurHaulsMay2922:48:34 dg01 kernel: BIOS-provided physical RAM map:。
--上面这部分是启动正常重启的日志shutdown –h now时输入信息如下：[root@dg01 log]shutdown –h now[root@dg01 log]# less messagesMay2923:53:45 dg01 syslogd 1.4.1: restart.May3004:02:29 dg01 shutdown[7138]: shutting down for system haltMay3004:02:31 dg01 smartd[3338]: smartd received signal 15: TerminatedMay3004:02:31 dg01 smartd[3338]: smartd is exiting (exit status 0)May3004:02:31 dg01 avahi-daemon[3266]: Got SIGTERM, quitting.May3004:02:31 dg01 avahi-daemon[3266]: Leaving mDNS multicast group on interfac e bond0.IPv6with address fe80::a00:27ff:fea5:4e59.May3004:02:31 dg01 avahi-daemon[3266]: Leaving mDNS multicast group on interfac e bond0.IPv4with address 192.168.56.110.May3004:02:33 dg01 xinetd[2925]: Exiting...May3004:02:37 dg01 hcid[2689]: Got disconnected from the system message bus May3004:02:37 dg01 multipathd: mpath1: stop event checker thread (1075239232) May3004:02:37 dg01 multipathd: --------shut down-------May3004:02:38 dg01 auditd[2506]: The audit daemon is exiting.May3004:02:38 dg01 kernel: type=1305 audit(1401436958.027:326): audit_pid=0 old=2 506 auid=4294967295 ses=4294967295 res=1May3004:02:38 dg01 pcscd: pcscdaemon.c:572:signal_trap() Preparing for suicide May3004:02:38 dg01 pcscd: hotplug_libusb.c:376:HPRescanUsbBus() Hotplug stoppe dMay3004:02:39 dg01 pcscd: readerfactory.c:1379:RFCleanupReaders() entering clean ing functionMay3004:02:39 dg01 pcscd: pcscdaemon.c:532:at_exit() cleaning /var/runMay3004:02:39 dg01 kernel: Kernel logging (proc) stopped.May3004:02:39 dg01 kernel: Kernel log daemon terminating.May3004:02:40 dg01 exiting on signal 15--这里也看见有May3004:02:29 dg01 shutdown[7138]: shutting down for system halt表示是正常关机而如果意外关机，输入日志中看不到正常关闭系统的信息，比如如下的日志信息：May2504:03:02APPServer4 syslogd 1.4.1: restart.May2613:26:04APPServer4 auditd[2985]: Audit daemon rotating log filesMay2901:50:34APPServer4 auditd[2985]: Audit daemon rotating log filesMay2923:07:01APPServer4 syslogd 1.4.1: restart.May2923:07:01APPServer4 kernel: klogd 1.4.1, log source = /proc/kmsg started.May2923:07:01APPServer4 kernel: Linux version 2.6.18-194.el5 (mockbuild@builder1 ) (gcc version 4.1.220080704 (RedHat4.1.2-48)) #1 SMP Fri Apr 2 14:58: 14 EDT 2010May2923:07:01APPServer4 kernel: Command line: ro root=LABEL=/ rhgb quietMay2923:07:01APPServer4 kernel: BIOS-provided physical RAM map:May2923:07:01APPServer4 kernel: BIOS-e820: 0000000000010000 - 000000000009b c00 (usable)May2923:07:01APPServer4 kernel: BIOS-e820: 000000000009bc00 - 00000000000a0 000 (reserved)May2923:07:01APPServer4 kernel: BIOS-e820: 00000000000e0000 - 0000000000100 000 (reserved)May2923:07:01APPServer4 kernel: BIOS-e820: 0000000000100000 - 00000000cff4b4 80 (usable)May2923:07:01APPServer4 kernel: BIOS-e820: 00000000cff4b480 - 00000000cff57b4 0 (ACPI data)May2923:07:01APPServer4 kernel: BIOS-e820: 00000000cff57b40 - 00000000e00000 00 (reserved)May2923:07:01APPServer4 kernel: BIOS-e820: 00000000fec00000 - 00000001000000 00 (reserved)May2923:07:01APPServer4 kernel: BIOS-e820: 0000000100000000 - 00000003b0000 000 (usable)May2923:07:01APPServer4 kernel: DMI 2.4 present.Os只是May2923:07:01APPServer4 kernel: klogd 1.4.1, log source = /proc/kmsg start ed.进行了重启，但是之前并没有输出任何正常关机的命令，这个就需要我们配合硬件日志来进行捕捉系统宕机原因了。