// 此模板仅供参考，如果不适用可以修改
问题描述
对服务器做AC cycle，每次抓取sel log，记录里边的system boot出现的次数，有时候sel log会记录两次systemc boot，有时候会记录一次。有遇到过类似的问题吗
环境信息
- 软件版本：25.12
答案内容由AI生成，仅供参考：
总结
| 项目 | 内容 |
|---|---|
| 问题现象 | AC Cycle后SEL日志中System Boot事件记录次数不稳定（1次或2次） |
| 根本原因 | 可能因BMC启动检测逻辑未能正确识别单一AC重启事件，导致误判为多次启动 |
| 相关组件 | SEL Log、System Boot Initiated #0x04、GetSysRstDetected、Fructrl |
| 验证方式 | 一键日志收集 + SEL日志比对 + app.log分析 |
| 解决建议 | 1. 增强事件去重逻辑； 2. 修复GetSysRstDetected类型错误； 3. 清理AC重启状态残留 |
推荐操作：执行“One-Click Collection of the openUBMC Log”获取完整日志包，上传后由研发团队分析具体触发条件。
点击此处查看详细分析解答
AC重启过程中SEL日志中System Boot记录次数不一致问题分析
问题描述
在对服务器执行AC Cycle（交流电源循环）操作时，通过抓取SEL Log（System Event Log） 发现“System Boot”事件的记录次数存在不一致现象：
- 有时SEL日志中记录了一次System Boot事件；
- 有时则记录了两次System Boot事件。
该异常行为发生在软件版本为 25.12 的环境下，用户关注此现象是否会影响系统稳定性或日志诊断准确性，并希望了解是否有类似案例及根本原因分析。
根本原因分析
根据提供的知识库信息，结合系统架构与日志行为，可能的原因如下：
1. 系统重启过程中的多阶段启动触发
在AC上电过程中，系统可能会经历多个阶段的初始化过程，导致IPMI或BMC识别出多次“启动”事件。
- 每次AC Cycle会触发硬件级的完整上下电流程。
- 在某些固件逻辑中，若BMC与Host之间的通信状态未正确同步，在Host尚未完全启动前，BMC可能误判为新一轮的启动事件，从而记录两次
System Boot Initiated #0x04事件。
相关证据：
- 文档中提到：“在AC/DC/BMC重启长时间脚本中检查”是常见测试场景（来源：search_result id=1），说明此类重启场景本身就可能引入瞬态告警或重复事件。
System Boot Initiated #0x04是标准IPMI事件，用于指示系统启动的开始，其被多次记录表明系统感知到了多次启动信号。
2. SEL日志记录机制与启动源判断逻辑问题
SEL日志中记录的System Boot / Restart Initiated Event事件由BMC基于IPMI规范生成，事件的触发依赖于启动源检测机制（如按钮、命令、看门狗等）。
- 若AC重启过程中存在电源不稳定或反复尝试上电的情况，可能导致BMC认为发生了两次不同的“启动请求”，进而记录两次事件。
- 特别是在AC Cycle测试中，如果电源恢复较快，某些硬件模块（如PSU、CPLD）未完全放电，可能造成状态不一致。
相关实体：
- Power Supply #0x27 的AC电源丢失可能与系统重启事件相关联。
- SEL Log 会记录
System Boot Initiated #0x04事件，在特定条件下可能出现重复记录。
3. BMC平滑重启机制与CPLD状态同步延迟
在openUBMC系统中，存在BMC平滑重启和CPLD升级生效机制，该机制会影响重启事件的判断。
- 根据《openUBMC支持CPLD升级平滑生效特性设计说明书》：
- BMC重启类型包括：平滑重启、强制复位、看门狗重启、AC下电重启。
- BMC重启时会读取重启原因寄存器，判断重启类型。
- 如果由于CPLD状态未及时清除或重启标志未被正确归零，在AC重启后可能误将“状态恢复”识别为“新的启动事件”。
4. 日志抑制机制或过滤策略影响
openUBMC框架具备日志防刷屏机制，会对连续相同日志进行合并或抑制。
- 文档中明确提到：“日志频繁打印，会冲掉历史日志，影响可定位性”。
- 同时也指出“框架日志过滤SmcDfxInfo的日志”（来自文档chunk 2），说明系统存在主动的日志过滤行为。
矛盾点：
- 理论上应抑制重复日志，但在此处反而出现“偶发多条”，说明事件并非简单重复，而是被系统识别为两次独立事件。
- 因此更可能是两次真实的触发动作，而非日志层问题。
验证方法建议
1. 获取完整的“一键日志”进行分析
使用 “One-Click Collection of the openUBMC Log” 功能收集完整诊断信息，重点查看：
dump_info\AppDump\event\sel.txt：原始SEL日志，确认System Boot事件的具体时间戳与关联事件；app.log和fructrl模块日志：查看是否有与SysRstDetected、PowerGDStatuschanged相关的状态变化；run_log_scp或run_log_nfs：运行日志中是否存在AC启动序列异常。
示例命令（若有CLI权限）：
ipmitool sel list | grep -i "system boot"
2. 比对多个AC Cycle的SEL日志模式
收集至少5次AC Cycle的SEL日志，分析以下内容：
| 次数 | System Boot事件数量 | 是否伴随其他异常事件（如IERR、ECC、Sensor Threshold） |
|---|---|---|
| 1 | 2 | 否 |
| 2 | 1 | 否 |
| 3 | 2 | 是（CPU Temp Recovery） |
若仅在某些条件下出现双记录，则需排查外部因素（如温度、电压波动）。
3. 检查GetSysRstDetected属性是否存在类型不匹配
文档中提到：
“The SysReset object in Fructrl uses the GetSysRstDetected property, which failed due to a type mismatch.”
若该属性读取失败，可能导致系统无法正确判断当前是否已处于重启流程，从而触发重复检测和记录。
解决方案建议
方案一：增强启动事件去重机制
在BMC事件处理逻辑中增加对“短时间内重复System Boot事件”的过滤机制：
- 设置时间窗口（如5秒内只接受一次System Boot记录）；
- 结合
CurrentRestartType属性判断是否属于同一重启周期。
实现路径：
if (event == "System Boot Initiated") and (time_since_last_boot < 5s):
log_suppress("Duplicate boot event suppressed")
else:
record_to_SEL()
方案二：优化AC重启状态同步逻辑
确保AC断电后所有状态标志（如sys_reset_flag）被彻底清除。
参考文档《上下电配置指导》：
dealwith_pwr_button_evt会设置sys_reset_flag为 true；- 应在AC断电完成时强制清零该标志，避免残留状态影响下次启动判断。
方案三：升级到修复该问题的版本
若此问题已被识别并修复，建议确认以下版本是否包含修复：
- 查询
iTestSmart 1.0.35是否修复了相关test case（参考Solution实体描述）； - 或确认新版本是否修复了
Fructrl模块中GetSysRstDetected的类型不匹配问题。
总结
| 项目 | 内容 |
|---|---|
| 问题现象 | AC Cycle后SEL日志中System Boot事件记录次数不稳定（1次或2次） |
| 根本原因 | 可能因BMC启动检测逻辑未能正确识别单一AC重启事件，导致误判为多次启动 |
| 相关组件 | SEL Log、System Boot Initiated #0x04、GetSysRstDetected、Fructrl |
| 验证方式 | 一键日志收集 + SEL日志比对 + app.log分析 |
| 解决建议 | 1. 增强事件去重逻辑； 2. 修复GetSysRstDetected类型错误； 3. 清理AC重启状态残留 |
是说同一次AC下，概率出现报两次事件吗？
是的
是否可以再进行复现，复现后一键收集日志并提供，便于明确该问题原因
有日志，我发给你
根据发的日志里记录的传感器历史事件，与你当前发帖截图不一致，发的日志里分析无该问题；请确认能否再次复现并提供新的日志