长时间做 AC 测试，出现 BMC 启动后十分钟 redfish 仍不通的情况

交流互助区
2

答案内容由AI生成，仅供参考：

长时间AC测试后BMC启动Redfish服务不通问题分析报告

问题概述

在基于社区930版本的系统中，进行长时间AC（上电/断电）循环测试时，出现 BMC启动后Redfish服务长达十分钟无法访问 的问题。该问题伴随 bmc_core 和 security 子系统的循环重启，约十几分钟后系统自动恢复。日志分析显示，此现象与 coredump生成 直接相关，且coredump的信号为 SIGSEGV（段错误），表明存在内存访问违规。

现象总结

现象 描述
Redfish服务不可达 BMC启动后超过10分钟无法通过HTTPS访问 /redfish/v1/ 接口，报错“Connection refused”
子系统循环重启 bmc_core 和 security 服务持续重启，日志中频繁出现 LAUNCH 和 KILL self 记录
coredump生成 系统中存在多个 core-skynet-11-bmc_core-... 和 core-skynet-11-security-... 文件，时间戳与故障时段一致
错误类型 core分析显示：Program terminated with signal SIGSEGV, Segmentation fault
关键函数 崩溃发生在 pcre2_compile_8() 函数中，来自库文件 /lib64/libpcre2-8.so.0

根本原因分析

1. 直接原因：PCRE2正则库引发段错误

  • 两个核心服务（bmc_core 和 security）的coredump均指向同一个函数：
    0x0000ffff8db0e078 in pcre2_compile_8 () from /lib64/libpcre2-8.so.0
  • pcre2_compile_8 是 PCRE2（Perl Compatible Regular Expressions） 库用于编译正则表达式的函数。
  • 出现 SIGSEGV（段错误） 表明在调用该函数时，程序试图访问非法内存地址，可能原因包括：
    • 传入了空指针或已被释放的字符串指针
    • 正则表达式字符串损坏或格式异常
    • 多线程环境下竞争条件导致内存状态不一致
    • 库版本兼容性问题或内存越界写入污染堆栈

结论：系统在启动过程中，bmc_core 或 security 模块在初始化阶段调用了 pcre2_compile_8 编译某个正则表达式时发生了内存访问违规，导致进程崩溃并触发 core dump。进程崩溃后由框架重启，但若问题依旧，则形成“启动 → 崩溃 → 重启”循环。

2. Redfish服务不可用的根本原因

  • Redfish服务依赖于 bmc_core 和 security 子系统正常运行。
  • 在 bmc_core 循环重启期间，其托管的服务（包括 Redfish 相关组件如 bmc.kepler.redfish）无法稳定加载。
  • 日志中显示：
    • bmc.kepler.redfish 是一个 D-Bus 服务，由 BMC 系统管理。
    • 若 bmc_core 进程反复崩溃，则 D-Bus 服务注册失败，服务文件缺失，导致 Redfish 启动失败。
  • 因此，Redfish 服务不通是 bmc_core 和 security 崩溃的连锁反应。

3. 为何AC测试会触发该问题？

AC测试涉及反复上下电，可能导致以下问题积累：

因素 潜在影响
频繁断电导致文件系统损坏风险 配置文件、证书、正则规则等数据可能被截断或写入异常
内存残留或状态未清理 虽然AC断电清除了内存，但固件层若未正确初始化某些模块，可能导致异常路径被执行
特定配置在重启后被重复加载 某些模块在每次启动时加载配置并尝试编译正则表达式，若配置异常则每次都触发崩溃
长时间运行后暴露边缘情况 崩溃可能只在特定配置组合或极低概率条件下触发，AC测试增加了暴露机会

4. 关联证据支持

（1）coredump时间与日志吻合

  • core文件名中时间戳（如 20260114170445）与 framework.log 中 KILL self 时间接近，说明崩溃真实发生且被捕获。

（2）bmc_core 和 security 同时崩溃

  • 两者均使用 skynet 框架，并共享部分底层库（如 libpcre2）。
  • 若某一通用组件（如日志解析、ACL规则匹配、证书校验）使用了正则表达式处理配置，且配置异常，则两个服务都可能受影响。

（3）Redfish依赖链中断

  • 关系图谱显示：
    {"entity1": "bmc", "entity2": "redfish", "description": "redfish is a service managed by the bmc system."}
  • bmc_core 是核心服务容器，其崩溃直接导致 Redfish 无法启动。

潜在触发点推测

根据崩溃发生在 pcre2_compile_8，可推测以下模块可能涉及：

模块 可能使用正则的场景 是否可疑
证书管理 / SSL 配置 解析证书DN字段、匹配主机名、校验证书策略 :white_check_mark: 高
安全策略（IAM） 用户名/角色匹配、IP黑白名单、访问控制规则 :white_check_mark: 高
日志过滤 / 调试规则 动态日志级别设置、关键字匹配 :white_check_mark: 中
配置文件解析 检查字段格式、版本号匹配等 :white_check_mark: 中

结合 社区版本 BMC 存在 SSL 证书导入问题 的已知缺陷（见知识库），极有可能是在证书处理或安全策略加载过程中，使用了PCRE2库解析某些字符串，而输入数据异常导致崩溃。

解决建议

:white_check_mark: 短期规避措施

  1. 清除异常配置

    • 检查并清除可能损坏的 SSL 证书、自定义安全规则或 ACL 配置。
    • 尝试恢复默认证书和安全策略后观察是否复现。

  2. 禁用非必要正则功能

    • 如有可配置的日志过滤、高级访问控制等功能，临时关闭以排除干扰。

  3. 升级 PCRE2 库

    • 检查 /lib64/libpcre2-8.so.0 的版本，升级至最新稳定版（如 v10.40+），修复可能存在的已知漏洞。

:white_check_mark: 根因修复建议

  1. 定位引发崩溃的具体模块

    • 使用以下命令提取 core 中的调用栈：
      gdb /opt/bmc/skynet/skynet core-skynet-11-security-20260114170445
(gdb) bt full
    • 查看完整调用栈，确定是哪一个业务模块调用了 pcre2_compile_8。

  2. 增加输入合法性校验

    • 所有传入 pcre2_compile_8 的字符串必须进行空指针、长度、合法性检查。
    • 添加 try/catch 或错误处理逻辑，防止因单个配置错误导致整个进程崩溃。

  3. 引入沙箱或独立进程模型

    • 将高风险模块（如证书解析、正则规则引擎）放入独立轻量进程，崩溃不影响主服务。

  4. 更新社区版本至修复版本

    • 社区版本 BMC 已知存在证书导入失败问题（如 OpenSSL 1.x 不兼容），建议升级至已知修复版本或官方推荐版本。

相关参考链接

总结

项目 内容
问题本质 bmc_core 与 security 服务因调用 pcre2_compile_8 发生段错误（SIGSEGV）而持续崩溃重启
根本原因 极可能是证书或安全策略配置异常导致正则编译失败，触发内存访问违规
Redfish不通原因 依赖的 bmc_core 服务未正常启动，Redfish D-Bus 服务无法注册
解决方案 1. 清理异常配置
2. 升级PCRE2库
3. 加强输入校验
4. 升级至稳定固件版本

建议立即采集完整的 backtrace 进行精准定位，并在测试环境中模拟复现以验证修复效果。

相关链接：

  1. X20 AC 测试过程中 产生core dump 导致bmc 重启
  2. 【教学培训篇】新增组件
  3. /redfish/v1/UpdateService/FirmwareInventory 多个属性缺失
  4. 【iTestSmart 1.0.36】手动配置IPv4地址模式下设置DNS模式为自动获取IPv4
  5. 网络管理常见问题指南 | 文档中心 | openUBMC