固件升级压力测试，异常报错，产生coredump

bmc_core SIG
1

基于2512_LTS版本构建的openUBMC

固件升级压测过程中BMC有异常重启的log，一键收集中有coredump：

image
image1586×650 30.4 KB

image
image1450×986 221 KB

因为coredump中没有unwind信息，.so也是strip过的，且security进程相关的组件基本是闭源的，难以定位，希望社区可以提供定位支持。
LogDump.zip (7.8 MB)
AppDump.zip (850.7 KB)

2

答案内容由AI生成，仅供参考：
:white_check_mark: 总结

项目 内容
问题本质 压力测试下 security 进程崩溃 → 触发 MACA 自动复位 → BMC 频繁重启
根本原因 security 组件在高并发Redfish会话/认证场景下存在稳定性缺陷（可能与类型不兼容、资源竞争或内存越界有关）
直接证据 coredump 文件存在；系统事件连续报 reset；security 为唯一异常进程
短期对策 降并发、禁用自动复位、检查UserId类型
长期对策 社区协助解析core、修复security模块、优化会话管理机制
点击此处查看详细分析解答

openUBMC 2512_LTS版本固件升级压力测试异常及coredump问题分析报告

根据您提供的详细日志、系统事件和coredump文件信息，针对基于 openUBMC 2512_LTS 版本在进行固件升级压力测试过程中出现的 BMC异常重启与security模块coredump 问题，结合知识库内容与系统机制，现进行系统性分析并提出解决建议。

:magnifying_glass_tilted_left: 问题概述

  • 现象：

    1. 在执行固件升级压力测试时，BMC出现多次异常重启。
    2. 系统事件日志显示 The openUBMC is reset, with the cause code of 0x2 和 0x10。
    3. 一键日志中发现多个 core-skyenet-* 类型的coredump文件，其中 core-skyenet-6-security-20260304102210 是最新且对应于最近一次异常的core文件。
    4. security 进程崩溃，且该组件为闭源组件，.so 文件已被strip，无调试符号和unwind信息，导致本地难以定位根因。

  • 关键线索：

    • 核心进程：security 发生coredump。
    • 异常时间点：2026-03-24 01:11 —— 与 security coredump 时间一致。
    • BMC重启事件码：0x2、0x10，对应 MACA组件掉线阈值触发复位 或 框架级复位。
    • 涉及版本：openUBMC 2512_LTS。

:puzzle_piece: 根本原因分析

一、BMC异常重启的根本原因：MACA机制检测到组件反复掉线

从日志中观察到多个连续的 BMC Reset 事件（事件码 0x2 和 0x10），结合 openUBMC 的微组件架构，此问题最可能由 MACA（Micro & Agile Component Architecture）的组件健康检查机制触发自动复位 所导致。

:white_check_mark: 相关知识库支持：

Document ID: 2（微组件管理介绍）

  • 组件在 10分钟内连续掉线5次，则复位BMC。
  • 所有组件总掉线次数累积达 2000次后也会复位BMC。
  • 默认最多复位3次，超过后仅记录不再复位。

结合此机制，security 进程频繁崩溃 → 触发掉线 → 达到阈值 → MACA 自动发起BMC复位，形成恶性循环。

:magnifying_glass_tilted_right: 推论链：

  1. security 进程在压力测试期间因高负载或并发访问异常崩溃（生成coredump）。
  2. 崩溃后由 init 或 kube-like 框架尝试重启。
  3. 但短时间内反复崩溃，导致“连续掉线”。
  4. 触发 MACA 的 连续5次掉线 或 累计2000次 逻辑。
  5. MACA 下发指令执行 BMC软复位，事件码为 0x2 或 0x10。
  6. 复位后系统重新启动，日志显示 openUBMC is reset and started。

:check_mark: 证据匹配：事件记录中多次出现 Reset/Started 成对出现，时间间隔短（如 22:00:08 ~ 22:14:26），符合“短时间高频异常后复位”的模式。

二、security 进程coredump的可能原因

尽管您指出 security 组件为闭源、.so 已 strip，缺乏调试信息，但我们仍可根据行为和环境推测可能原因。

1. 高并发会话创建导致资源竞争或内存越界

  • security 模块负责用户认证、会话管理、证书校验等敏感操作。
  • 固件升级压力测试往往伴随大量 Redfish API 调用（如创建会话 /redfish/v1/SessionService/Sessions）。
  • 若未做并发控制，多线程争抢共享资源（如会话表、TLS上下文）可能导致：
    • 内存越界
    • 使用已释放内存（use-after-free）
    • 死锁或栈溢出
    • 最终引发进程崩溃（coredump）

2. 与Redfish接口类型变更兼容性问题相关

Document ID: 6（Redfish接口变更声明）

  • 在 openUBMC 25.12 版本中，Oem/{OemIdentifier}/UserId 从字符串类型改为整数类型。
  • 若上层工具或脚本未适配，强制传参错误类型（如字符串 "2"），可能引起反序列化失败或类型转换崩溃。

:red_exclamation_mark: 特别提示：若您的压测脚本使用了旧逻辑发送字符串型 UserId，而新版固件期望整数，security 模块在解析时未做类型校验，可能触发非法操作。

3. 证书或密钥操作引发异常

  • security 模块通常处理 OpenSSL/BoringSSL 调用。
  • 在高频签名校验、证书导入/导出场景下：
    • SSL Context 初始化失败
    • BIO Buffer 操作异常
    • 异常中断导致锁未释放
  • 可能导致底层C代码抛出异常并 crash。

4. 资源耗尽（内存/文件描述符）

  • 长时间压力测试未释放资源 → fd leak / memory leak
  • ulimit 限制触达 → fork() 或 socket() 失败 → 进程异常退出
  • 日志中若有 cannot allocate memory 或 too many open files，可进一步确认。

:hammer_and_wrench: 解决方案与建议

:white_check_mark: 一、紧急缓解措施（防止持续重启）

措施 说明
临时禁用MACA自动复位机制 修改 manifest.yml 中的 maca 配置，设置：
max_reset_count: 0 或 disable_auto_reset: true
避免因临时异常导致设备不断重启，便于收集完整日志。
限制并发请求数量 修改压测脚本，降低并发度，引入速率控制（rate limiting），观察是否仍触发崩溃。

:white_check_mark: 二、根本性排查建议

1. 定位具体触发点

  • 分析 AppDump.zip 中的 app.log、framework.log，搜索以下关键词：
    grep -i "security\|crash\|core\|segfault\|abort" app.log
grep -i "StartupCheck failed" framework.log
  • 查看是否有以下记录：
    • bmc.kepler.security 启动失败
    • DBus 注册失败（ServiceUnknown）
    • TLS 握手失败或证书错误

2. 验证Redfish会话参数兼容性

  • 检查压测脚本中调用 /redfish/v1/SessionService/Sessions 时的 UserId 类型：
    { "Oem": { "Huawei": { "UserId": 2 } } }  // 正确：整数
    而非：
    { "Oem": { "Huawei": { "UserId": "2" } } }  // 错误：字符串
  • 若为字符串，请调整脚本并重测验证。

3. 检查security进程依赖项

  • 使用 ldd /usr/bin/security（如有权限）查看其动态依赖库。
  • 确认是否存在非标准库或旧版库（如旧版 OpenSSL）。
  • 检查 /etc/security/ 配置文件是否正确加载。

4. 尝试启用ASAN（地址消毒剂）

  • 若可构建定制版本，建议在编译 security 或其依赖库时开启 -fsanitize=address。
  • 虽然官方组件闭源，但部分中间件可能开源，可针对性增强检测能力。

:white_check_mark: 三、社区协作请求建议

鉴于 security 模块为闭源组件且缺少调试信息，建议向 openUBMC 社区提交正式技术协助请求，内容包括：

:open_mailbox_with_raised_flag: 提交信息清单：

  1. 问题标题：[求助] openUBMC 2512_LTS 压测期间 security 进程频繁coredump
  2. 环境信息：
    • 版本：openUBMC 2512_LTS
    • 硬件平台：请补充设备型号
    • 构建方式：是否基于社区源码修改？是否开启额外安全策略？
  3. 现象描述：
    • 多次BMC异常重启（事件码 0x2/0x10）
    • security 进程生成 core 文件（已提供）
  4. 附件上传：
    • core-skyenet-6-security-20260304102210（重点）
    • core-maps-...（辅助映射）
    • AppDump.zip, LogDump.zip
  5. 请求内容：

    请社区协助：

    • 提供 security 二进制的 unstripped 版本或符号表（.sym/.debug 文件）
    • 解析该 core 文件的调用栈（stack trace）
    • 判断是否为已知缺陷或近期补丁可修复

:white_check_mark: 推荐提交地址：https://discuss.openubmc.cn

:bar_chart: 建议后续测试优化

方向 建议
逐步加压测试 避免一次性高压，采用阶梯式增加并发数（如 10 → 50 → 100），定位临界点。
增加观测点 监控 /data/var/coredump/ 目录变化、dmesg 输出、DBus状态。
开启内核coredump配置 确保 /proc/sys/kernel/core_pattern 设置正确，避免丢失。
关闭非必要服务 排除干扰，仅保留 security、redfish、maca 相关组件运行。

:white_check_mark: 总结

项目 内容
问题本质 压力测试下 security 进程崩溃 → 触发 MACA 自动复位 → BMC 频繁重启
根本原因 security 组件在高并发Redfish会话/认证场景下存在稳定性缺陷（可能与类型不兼容、资源竞争或内存越界有关）
直接证据 coredump 文件存在；系统事件连续报 reset；security 为唯一异常进程
短期对策 降并发、禁用自动复位、检查UserId类型
长期对策 社区协助解析core、修复security模块、优化会话管理机制

:pushpin: 建议立即行动：
将 core-skyenet-6-security-20260304102210 及相关日志打包，提交至 openUBMC 官方论坛，并附上压测脚本节选（特别是会话创建部分），以获取闭源组件的官方支持。

如需协助撰写社区求助帖，我可为您起草模板。