devmon 总是报:service_backend dispatch error:

交流互助区
1

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

问题描述

devmon ERROR: debug.cpp(437): Failed to load debug config via DBus: : protocol (bmc.kepler.persistence)
2026-08-05 03:49:01.727784 devmon WARNING: service_backend.cpp(100): service_backend dispatch error: bmc.kepler.devmon /bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1 bmc.dev.NetworkPort.SetLLDPTxEnable: mc.engine.unknown_object: {“name”:“mc.engine.unknown_object”,“format”:“Unknown object /bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1”,“params”:[“/bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1”]}
2026-08-05 03:49:01.750987 devmon NOTICE: topology_discovery.cpp(150): start to init topology discovery

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：最新版本的mainfest拉下来编译的bmc固件 2609

    image
    image1101×421 18.9 KB

  • 硬件配置：宝德的 鲲鹏PR210KPRO

重现步骤

  1. 编译最新版本的mainfest 出rootfs_openUBMC.hpm。

  2. bmc 版本2606升级rootfs_openUBMC.hpm。

  3. 查看cat /var/log/app.log | grep devmon

image
image2557×277 29.4 KB

期望结果

PR210KPRO_PR210KPRO250821BJJS00450_20260805-0357.tar.gz (25.1 MB)

[您希望实现什么]

实际结果

[实际发生了什么，包含错误信息]

尝试过的解决方案

[列出您已经尝试过的解决方案及结果]

分析结论

[详细总结您对此问题的分析结论]

2

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

分析结论

基于知识库（Knowledge Graph、Document Chunks）中的信息，以下原因可能导致此问题：

1. devmon 服务未能正确注册或启动

  • 知识库中多次记录 bmc.kepler.devmon 服务因缺少 .service 文件而无法被系统识别，导致其他组件获取 devmon 对象时返回 org.freedesktop.DBus.Error.ServiceUnknown（参考文档块 [1]、[2]）。
  • 尽管当前 devmon 进程有日志输出，但若其 D‑Bus 服务未正确注册（例如 .service 文件缺失或软链接配置错误），对象树可能无法被其他服务正常访问，甚至 devmon 自身也可能在启动过程中部分失败。
  • 在 openUBMC 26.06 版本中，devmon 曾出现反复重启（ABRT 信号）的问题（知识图谱 devmon 实体），这可能导致对象树构建不完整。

2. 设备对象树初始化失败

  • devmon 的核心职责是管理设备对象（如 PCIe 网卡）的发现、注册与生命周期（知识图谱 devmon 实体描述）。若其初始化阶段出现问题（例如依赖的南向组件缺失、驱动加载失败），则对应的对象路径不会在 D‑Bus 上暴露。
  • 知识库明确指出 devmon 1.2.23 版本存在芯片节点创建失败的问题（devmon 实体描述），其他版本也可能因驱动加载错误（如 class not found）导致 PCIe 网卡对象无法建立。
  • 错误日志中的 Unknown object 表明该 NicPort/1 对象从未被注册，直接印证了对象树缺失。

3. 依赖服务缺失

  • 日志中另一错误 Failed to load debug config via DBus: protocol (bmc.kepler.persistence) 提示 bmc.kepler.persistence 服务不可用。虽然知识库中未直接描述该服务，但 devmon 的调试配置依赖它，该服务的缺失可能进一步导致 devmon 初始化异常，影响对象注册过程。
  • devmon 的正常运行依赖于 Southbound Components（如 hwdiscovery、component_drivers 等）。知识库中记录 Devmon Service 因缺少南向组件而无法加载（Devmon Service 实体）。

4. 版本兼容性问题

  • 知识库中 devmon 存在多个版本（1.1.25 ~ 1.70.119），不同版本的行为存在差异。当前使用的最新 manifest 编译版本可能与特定硬件驱动或依赖库不兼容，导致对象创建失败。
  • hwdiscovery 组件出现过版本依赖范围错误（>1.0.0, <1.90.0），若版本不匹配同样会影响设备发现。

建议解决方案（基于知识库中的已知方法）

  1. 确保 devmon 的 D‑Bus 服务文件正确配置

    • 在文档块 [2]（topic 3321）中，类似问题的解决办法是：不要直接新建 devmon.service，而应在 /etc/systemd/system/multi-user.target.wants/ 下创建指向实际 devmon.service 的软链接。拉取正确的 PR 分支（PR_235）可以自动生成该配置。
    • 验证当前系统中是否存在 bmc.kepler.devmon.service 文件，并检查软链接是否正确。

  2. 检查依赖组件是否完整

    • 确认 hwdiscovery、component_drivers 等南向组件版本是否与 devmon 兼容（参考知识库中版本范围）。
    • 确保 bmc.kepler.persistence 等服务已正确安装（该服务可能属于 persistence 组件）。

  3. 验证硬件驱动加载

    • 通过 devmon 日志（如 chip.cpp 中的错误）检查 PCIe 网卡驱动是否成功加载。若驱动 class 未找到，需确认对应的 .so 文件已正确部署于 component_drivers 目录。
    • 参考知识库中的记录：devmon 在驱动加载失败时会记录 class not found 警告。

  4. 尝试切换 devmon 版本

    • 若当前 devmon 版本（可能为 1.2.23 或相近版本）已知存在节点创建问题，可升级或回退至稳定的版本（如 1.70.x 系列），但需同时适配依赖库。

总结

当前 service_backend dispatch error 的根本原因很可能是 devmon 对象树未完整构建：D‑Bus 上缺少预期对象路径，导致网卡接口调度失败。这通常由 devmon 服务注册异常、依赖组件缺失、驱动加载失败或版本不兼容引起。建议从 .service 文件配置完整性、南向组件依赖及驱动加载日志入手排查。

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

根据您提供的日志信息（service_backend dispatch error、mc.engine.unknown_object）以及问题描述，结合知识库中的相关信息，对这一问题进行如下分析。

问题描述

  • 错误日志：
    • devmon ERROR: debug.cpp(437): Failed to load debug config via DBus: : protocol (bmc.kepler.persistence)
    • devmon WARNING: service_backend.cpp(100): service_backend dispatch error: bmc.kepler.devmon ... SetLLDPTxEnable: mc.engine.unknown_object: {“name”:“mc.engine.unknown_object”,“format”:“Unknown object .../NicPort/1”}
  • 环境信息：
    • 软件版本：基于最新 manifest 编译的 openUBMC（2609 版本）
    • 硬件：鲲鹏服务器平台（具体型号 PR210KPRO，但知识库中无此硬件的直接描述）

日志表明 devmon 在尝试对对象路径 /bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1 调度 SetLLDPTxEnable 时，该对象不存在（unknown_object），同时 debug 配置加载失败。

分析结论

基于知识库（Knowledge Graph、Document Chunks）中的信息，以下原因可能导致此问题：

1. devmon 服务未能正确注册或启动

  • 知识库中多次记录 bmc.kepler.devmon 服务因缺少 .service 文件而无法被系统识别，导致其他组件获取 devmon 对象时返回 org.freedesktop.DBus.Error.ServiceUnknown（参考文档块 [1]、[2]）。
  • 尽管当前 devmon 进程有日志输出，但若其 D‑Bus 服务未正确注册（例如 .service 文件缺失或软链接配置错误），对象树可能无法被其他服务正常访问，甚至 devmon 自身也可能在启动过程中部分失败。
  • 在 openUBMC 26.06 版本中，devmon 曾出现反复重启（ABRT 信号）的问题（知识图谱 devmon 实体），这可能导致对象树构建不完整。

2. 设备对象树初始化失败

  • devmon 的核心职责是管理设备对象（如 PCIe 网卡）的发现、注册与生命周期（知识图谱 devmon 实体描述）。若其初始化阶段出现问题（例如依赖的南向组件缺失、驱动加载失败），则对应的对象路径不会在 D‑Bus 上暴露。
  • 知识库明确指出 devmon 1.2.23 版本存在芯片节点创建失败的问题（devmon 实体描述），其他版本也可能因驱动加载错误（如 class not found）导致 PCIe 网卡对象无法建立。
  • 错误日志中的 Unknown object 表明该 NicPort/1 对象从未被注册，直接印证了对象树缺失。

3. 依赖服务缺失

  • 日志中另一错误 Failed to load debug config via DBus: protocol (bmc.kepler.persistence) 提示 bmc.kepler.persistence 服务不可用。虽然知识库中未直接描述该服务，但 devmon 的调试配置依赖它，该服务的缺失可能进一步导致 devmon 初始化异常，影响对象注册过程。
  • devmon 的正常运行依赖于 Southbound Components（如 hwdiscovery、component_drivers 等）。知识库中记录 Devmon Service 因缺少南向组件而无法加载（Devmon Service 实体）。

4. 版本兼容性问题

  • 知识库中 devmon 存在多个版本（1.1.25 ~ 1.70.119），不同版本的行为存在差异。当前使用的最新 manifest 编译版本可能与特定硬件驱动或依赖库不兼容，导致对象创建失败。
  • hwdiscovery 组件出现过版本依赖范围错误（>1.0.0, <1.90.0），若版本不匹配同样会影响设备发现。

建议解决方案（基于知识库中的已知方法）

  1. 确保 devmon 的 D‑Bus 服务文件正确配置

    • 在文档块 [2]（topic 3321）中，类似问题的解决办法是：不要直接新建 devmon.service，而应在 /etc/systemd/system/multi-user.target.wants/ 下创建指向实际 devmon.service 的软链接。拉取正确的 PR 分支（PR_235）可以自动生成该配置。
    • 验证当前系统中是否存在 bmc.kepler.devmon.service 文件，并检查软链接是否正确。

  2. 检查依赖组件是否完整

    • 确认 hwdiscovery、component_drivers 等南向组件版本是否与 devmon 兼容（参考知识库中版本范围）。
    • 确保 bmc.kepler.persistence 等服务已正确安装（该服务可能属于 persistence 组件）。

  3. 验证硬件驱动加载

    • 通过 devmon 日志（如 chip.cpp 中的错误）检查 PCIe 网卡驱动是否成功加载。若驱动 class 未找到，需确认对应的 .so 文件已正确部署于 component_drivers 目录。
    • 参考知识库中的记录：devmon 在驱动加载失败时会记录 class not found 警告。

  4. 尝试切换 devmon 版本

    • 若当前 devmon 版本（可能为 1.2.23 或相近版本）已知存在节点创建问题，可升级或回退至稳定的版本（如 1.70.x 系列），但需同时适配依赖库。

总结

当前 service_backend dispatch error 的根本原因很可能是 devmon 对象树未完整构建：D‑Bus 上缺少预期对象路径，导致网卡接口调度失败。这通常由 devmon 服务注册异常、依赖组件缺失、驱动加载失败或版本不兼容引起。建议从 .service 文件配置完整性、南向组件依赖及驱动加载日志入手排查。

3

前一次加载已经完成了网卡的加载

2026-08-05 03:48:52.138176 devmon NOTICE: devmon_root_interface.cpp(149): AddDevice done pos=0101010301 uptime=237

journalctl 日志里能看到devmon发生了异常重启

2026-08-05T03:48:57+0000 PR210KPRO250821BJJS00450 systemd[1]: devmon.service: Main process exited, code=killed, status=6/ABRT
2026-08-05T03:48:57+0000 PR210KPRO250821BJJS00450 systemd[1]: devmon.service: Failed with result ‘signal’.

结合日志可以观察到，应当是devmon在网卡业务中发生了异常重启，对应的资源卸载，network_adapter在往网卡发送请求时对象不存在

2026-08-05 03:49:01.727784 devmon WARNING: service_backend.cpp(100): service_backend dispatch error: bmc.kepler.devmon /bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1 bmc.dev.NetworkPort.SetLLDPTxEnable: mc.engine.unknown_object: {“name”:“mc.engine.unknown_object”,“format”:“Unknown object /bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1”,“params”:[“/bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1”]}
2026-08-05 03:49:01.734550 network_adapter ERROR: port_property_listen.lua(51): set lldp tx enabled failed for port PCIeCard1(N20H-R2F-100G)2, err is mc.engine.unknown_object: Unknown object /bmc/dev/Systems/1/PCIeNicCard/PCIeNicCard_1_0101010301/NicPort/1