问题描述
长时间做 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_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 模块在初始化阶段调用了 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依赖链中断
潜在触发点推测
根据崩溃发生在 pcre2_compile_8,可推测以下模块可能涉及:
模块
可能使用正则的场景
是否可疑
证书管理 / SSL 配置
解析证书DN字段、匹配主机名、校验证书策略
高
安全策略(IAM)
用户名/角色匹配、IP黑白名单、访问控制规则
高
日志过滤 / 调试规则
动态日志级别设置、关键字匹配
中
配置文件解析
检查字段格式、版本号匹配等
中
结合 社区版本 BMC 存在 SSL 证书导入问题 的已知缺陷(见知识库),极有可能是在证书处理或安全策略加载过程中,使用了PCRE2库解析某些字符串,而输入数据异常导致崩溃 。
解决建议
短期规避措施
清除异常配置
检查并清除可能损坏的 SSL 证书、自定义安全规则或 ACL 配置。
尝试恢复默认证书和安全策略后观察是否复现。
禁用非必要正则功能
如有可配置的日志过滤、高级访问控制等功能,临时关闭以排除干扰。
升级 PCRE2 库
检查 /lib64/libpcre2-8.so.0 的版本,升级至最新稳定版(如 v10.40+),修复可能存在的已知漏洞。
根因修复建议
定位引发崩溃的具体模块
增加输入合法性校验
所有传入 pcre2_compile_8 的字符串必须进行空指针、长度、合法性检查。
添加 try/catch 或错误处理逻辑,防止因单个配置错误导致整个进程崩溃。
引入沙箱或独立进程模型
将高风险模块(如证书解析、正则规则引擎)放入独立轻量进程,崩溃不影响主服务。
更新社区版本至修复版本
社区版本 BMC 已知存在证书导入失败问题(如 OpenSSL 1.x 不兼容),建议升级至已知修复版本或官方推荐版本。
相关参考链接
总结
项目
内容
问题本质
bmc_core 与 security 服务因调用 pcre2_compile_8 发生段错误(SIGSEGV)而持续崩溃重启
根本原因
极可能是证书或安全策略配置异常导致正则编译失败,触发内存访问违规
Redfish不通原因
依赖的 bmc_core 服务未正常启动,Redfish D-Bus 服务无法注册
解决方案
1. 清理异常配置 2. 升级PCRE2库 3. 加强输入校验 4. 升级至稳定固件版本
建议立即采集完整的 backtrace 进行精准定位,并在测试环境中模拟复现以验证修复效果。
相关链接:
X20 AC 测试过程中 产生core dump 导致bmc 重启
【教学培训篇】新增组件
/redfish/v1/UpdateService/FirmwareInventory 多个属性缺失
【iTestSmart 1.0.36】手动配置IPv4地址模式下设置DNS模式为自动获取IPv4
网络管理常见问题指南 | 文档中心 | openUBMC
wangxin
(Wangxin)
2026 年2 月 4 日 01:45
3
你好,请提供下coredump文件、一键日志收集文件和对应版本包,供进一步分析