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

问题描述

长时间做 AC 测试,出现 BMC 启动后十分钟 redfish 仍不通的情况,且伴有 bmc_core 和 security 子系统循环重启,十几分钟后恢复

环境信息

基于社区 930 版本

问题现象

子系统有循环重启

redfish 访问不通

该时间点伴随 coredump 生成

解 core 结果:

Core was generated by `security /opt/bmc/apps/hica/subsys/security/config.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000ffff8db0e078 in pcre2_compile_8 () from /lib64/libpcre2-8.so.0
[Current thread is 1 (LWP 8517)]
Core was generated by `bmc_core /opt/bmc/apps/hica/subsys/bmc_core/config.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000ffff89650078 in pcre2_compile_8 () from /lib64/libpcre2-8.so.0
[Current thread is 1 (LWP 8460)]

答案内容由AI生成,仅供参考:

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

问题概述

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


现象总结

现象 描述
Redfish服务不可达 BMC启动后超过10分钟无法通过HTTPS访问 /redfish/v1/ 接口,报错“Connection refused”
子系统循环重启 bmc_coresecurity 服务持续重启,日志中频繁出现 LAUNCHKILL 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_coresecurity)的coredump均指向同一个函数:
    0x0000ffff8db0e078 in pcre2_compile_8 () from /lib64/libpcre2-8.so.0
    
  • pcre2_compile_8PCRE2(Perl Compatible Regular Expressions) 库用于编译正则表达式的函数。
  • 出现 SIGSEGV(段错误) 表明在调用该函数时,程序试图访问非法内存地址,可能原因包括:
    • 传入了空指针或已被释放的字符串指针
    • 正则表达式字符串损坏或格式异常
    • 多线程环境下竞争条件导致内存状态不一致
    • 库版本兼容性问题或内存越界写入污染堆栈

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


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

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

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_coresecurity 服务因调用 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

你好,请提供下coredump文件、一键日志收集文件和对应版本包,供进一步分析

需要提供邮件地址提问者才可以发你邮箱呢。

wangxin570@huawei.com