BMC异常卡顿，有HealthCheck failed打印，sensor异常重启，随后BMC恢复正常

交流互助区
1

// 此模板仅供参考，如果不适用可以修改

问题描述

BMC异常卡顿，有HealthCheck failed打印，组件有重启，随后BMC恢复正常

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：OpenUBMC2512

  • 硬件配置：[如 CPU、内存等]

重现步骤

  1. 无

期望结果

BMC运行正常

实际结果

Web上响应非常慢，加载操作日志之类的页面需要3到5秒，一键收集日志等了5分钟进度一直0，BMC后台ipmcget -d v需要2分钟左右才会返回结果；十几分钟后卡顿结束，收集日志正常

3a51e5d41443dd9589c0449b06ad8445
3a51e5d41443dd9589c0449b06ad84451920×1012 192 KB

a1618266efd608a0dd4d6358c8dc5dcc
a1618266efd608a0dd4d6358c8dc5dcc1920×1016 200 KB

尝试过的解决方案

查看BMC日志，发现异常打印

分析结论

framework日志有HealthCheck failed打印，组件有重启

image
image1464×593 69.7 KB

一键日志

R220KV2_2101311ECC10R6100001_20260517-0950.tar.gz (8.1 MB)

bmc的web卡顿，执行ipmtool命令查询sensor列表超时
2

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

总结

项目 内容
问题本质 系统负载过高 → D-Bus 通信超时 → 组件 HealthCheck 失败 → 被 MACA 重启 → 加剧负载 → 引发卡顿
直接表现 Web 响应慢、CLI 命令延迟、日志中大量 HealthCheck failed 和组件重启记录
根本原因 系统内部消息队列积压严重，导致通信阻塞与组件行为异常
解决方案 1. 排查负载源
2. 优化健康检查机制
3. 升级至 LTS 稳定版本
4. 加强监控与日志管理
是否可自愈 是，系统具备有限容错与恢复能力，通常在十几分钟内恢复

:pushpin: 建议行动：优先排查系统是否存在异常调用行为，并计划将 BMC 固件升级至 openUBMC 2512LTS 以提高稳定性。

点击此处查看详细分析解答

BMC 异常卡顿问题分析与处理报告

问题概述

用户报告 BMC 出现严重卡顿现象，表现为 Web 界面响应缓慢（加载页面需 3–5 秒）、一键日志收集长时间无进展（5 分钟仍显示 0%）、ipmcget -d v 命令执行耗时约 2 分钟才返回结果。约十几分钟后系统自动恢复正常。

系统环境为 openUBMC 版本 25.12（具体版本号：25.12.90.03），硬件平台正常运行，所有关键组件均在位。

现象描述

  • Web 界面响应极慢，操作日志等页面加载延迟明显。
  • 一键信息收集卡在 0%，长时间无法完成。
  • CLI 命令执行延迟极高，如 ipmcget -d v 需等待近两分钟才返回。
  • 卡顿持续约十几分钟后自动恢复，系统恢复正常服务。
  • BMC 日志中存在大量 HealthCheck failed 打印，并伴随多个组件重启行为。
  • 终端中曾出现如下错误提示：
    The request failed due to an internal service error. The service is still operational.
Request failed.

根本原因分析

根据提供的日志内容及系统行为信息，本次 BMC 卡顿的根本原因已定位如下：

1. 组件健康检查失败触发连锁重启

日志显示以下关键错误：

maca ERROR: init.lua(62): [component]Healthcheck failed, error: org.freedesktop.DBus.Error.NoReply: Did not receive a reply.
maca ERROR: init.lua(62): [sensor]Healthcheck failed...
maca ERROR: init.lua(62): [host_agent]Healthcheck failed...

这表明多个核心组件（如 sensor、host_agent、frudata、event）在周期性健康检查中未能及时响应，导致 MACA（管理控制器健康代理）判定其异常并发起重启。

该现象符合 MACA 框架的容错机制设计：当组件无法响应 D-Bus 请求时，MACA 会记录 NoReply 错误，并在达到阈值后尝试重启组件以恢复服务。

2. 消息队列积压，系统负载过载

日志中发现如下高危警告：

[:000000b] alarm: May overload, message queue length = 2244
[:00000012] interface: May overload, message queue length = 1608
[:00000012] interface: May overload, message queue length = 2994

消息队列长度超过 2000，表明系统内部通信严重堵塞，Skynet 框架的消息处理能力已达瓶颈。

这极可能导致：

  • D-Bus 通信超时；
  • 组件间调用阻塞；
  • HealthCheck 无法及时收到响应，从而误判为组件故障；
  • 进一步引发不必要的组件重启，形成“异常检测 → 重启 → 加重负载 → 更多异常”的恶性循环。

3. 组件频繁重启加剧系统拥堵

日志还记录了如下信息：

maca NOTICE: base.lua(334): component[sensor] exited total 1 times, total 1 times for all modules
maca NOTICE: base.lua(334): component[frudata] exited total 1 times, total 2 times...
maca NOTICE: base.lua(334): component[host_agent] exited total 1 times, total 3 times...

多个组件被 MACA 重启，每次重启都会带来额外的资源开销（初始化、注册服务、重建连接等），进一步加重本已过载的系统负载，延长恢复时间。

此外，host_agent 组件还报出：

Unknown object path /bmc/kepler/host_agent/MicroComponent

说明其服务未完全启动或 D-Bus 注册失败，可能与其重启过程中依赖项尚未就绪有关。

4. 系统最终自我恢复机制生效

尽管经历严重卡顿和组件震荡，系统在十几分钟后恢复正常。这得益于以下几点：

  • MACA 的 有限重启机制（默认最多重启 3 次）防止了无限重启；
  • 重启动作释放了部分积压资源；
  • 高负载状态随时间缓解，消息队列逐步清空；
  • 各组件最终成功注册并稳定运行。

关联知识库信息验证

现象 对应知识库信息
HealthCheck failed 和组件重启 来自 Document Chunk 1，MACA 组件具备健康检查与自动重启机制；当日志中出现 "continuously offline 5 time within 10 minutes" 且未触发 BMC 复位，说明已达到最大重置次数（默认 3 次）
org.freedesktop.DBus.Error.NoReply 说明 D-Bus 调用超时，常见于组件未响应或主线程阻塞
消息队列积压 日志中的 message queue length = 2244 与 Skynet 框架过载表现一致，属于典型性能瓶颈
Web 响应慢、CLI 命令延迟高 与 load issue 概念相符：系统负荷过高导致响应延迟

解决方案与建议

:white_check_mark: 已验证的临时缓解措施

  • 重启 BMC 可快速恢复系统（已由历史案例验证）；
  • 若问题偶发且短暂，系统具备自愈能力，可观察是否自动恢复。

:wrench: 根本性优化建议

1. 排查高负载源头

检查以下可能造成系统高负载的原因：

  • 是否存在频繁调用 Redfish API 或 IPMI 命令的外部监控系统？
  • 是否运行了高开销的任务（如频繁收集传感器数据、日志轮转密集等）？
  • 是否有自定义应用（如 my_app）存在无限循环或阻塞操作？

建议使用 top、htop 或 skynet_profiler 工具定位 CPU 和内存占用最高的进程。

2. 优化健康检查策略

  • 调整 MACA 的健康检查频率或超时阈值，避免在瞬时负载高峰误判。
  • 检查 /etc/maca/config.json 或相关配置文件中关于 HEALTH_CHECK_INTERVAL 和 HEALTH_CHECK_TIMEOUT 的设置。

3. 提升系统资源容量

  • 若 BMC 使用的是低性能 ARM 处理器或内存不足（如 <1GB RAM），考虑升级硬件。
  • 检查是否存在内存泄漏：对比多次重启前后的内存使用情况。

4. 更新至更稳定版本

当前使用版本为 openUBMC 25.12，该版本已被标记为 存在兼容性问题的 Legacy 版本（见 KG 中 openUBMC 25.12 描述）。

  • 建议升级至 长期支持版本 openUBMC 2512LTS（版本 25.12.00.02）。
  • 升级前确保：
    • 所有自定义组件兼容新版本；
    • 签名机制不会影响关键命令（如 tar）执行（参考类似升级失败案例）；
    • 备份当前配置和数据库。

5. 加强日志分析与监控

  • 启用更详细的日志级别（如 DEBUG）捕获首次异常发生时刻；
  • 配置外部日志服务器集中存储，便于事后分析；
  • 增加对 message queue length 的监控告警。

总结

项目 内容
问题本质 系统负载过高 → D-Bus 通信超时 → 组件 HealthCheck 失败 → 被 MACA 重启 → 加剧负载 → 引发卡顿
直接表现 Web 响应慢、CLI 命令延迟、日志中大量 HealthCheck failed 和组件重启记录
根本原因 系统内部消息队列积压严重，导致通信阻塞与组件行为异常
解决方案 1. 排查负载源
2. 优化健康检查机制
3. 升级至 LTS 稳定版本
4. 加强监控与日志管理
是否可自愈 是，系统具备有限容错与恢复能力，通常在十几分钟内恢复

:pushpin: 建议行动：优先排查系统是否存在异常调用行为，并计划将 BMC 固件升级至 openUBMC 2512LTS 以提高稳定性。

1 个赞
3

问题复现方法，2512上网包版本必现

1、上网包命令行开启sol会话，并设置串口到sys com，命令：ipmcset -t sol -d a -v 1 0

2、BMC开始卡顿，使用top命令，发现多个clp_comm占用cpu资源，目前发现最多有14个

3、在2512上网包版本上有该问题，切换到2603上网包版本无问题

截图

Snipaste_2026-04-30_15-56-04
Snipaste_2026-04-30_15-56-04787×405 211 KB

Snipaste_2026-04-30_15-27-08
Snipaste_2026-04-30_15-27-08787×340 159 KB

这个是已知问题吗？

4

是每次都伴随着 sensor 组件异常重启吗？这个非 sensor 已知问题，从描述看理论与 sensor 组件关系不大；若非特别需要，建议可以直接切为 2603 版本使用

5

不是 只是第一次问题出现时看到sensor重启，以为是sensor问题

6

只是重启1-5次属于正常情况，除非超过6次后框架才会复位bmc

7

上网包命令行开启sol会话，并设置串口到sys com后才出现的卡顿

8

启动阶段，framework.log除了组件启动失败的报错以外，还有什么其他异常日志吗

9

上网包命令行开启sol会话，并设置串口到sys com后才出现的卡顿

切换到LTS SP2后问题解决