如何查看新建的组件未起来的具体原因

交流互助区
2

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

:white_check_mark: 结论

新建组件未起来的根本原因通常来自以下几类：

  1. 配置缺失（如 launch_control_00_ff.json 缺失）
  2. 依赖服务不可用（D-Bus 接口未注册）
  3. Lua 代码异常未被捕获
  4. MACA 启动检查失败 → 触发回滚
  5. 编译/部署流程错误，代码未真正生效

:white_check_mark: 推荐做法：

在 main.lua 中使用 pcall(app.new) 包裹初始化逻辑，并优先检查 app.log 和 framework.log，确认是否执行到组件入口。

通过上述系统化的排查流程，可精准定位组件启动失败的具体环节。

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

如何查看新建组件未启动的具体原因（基于 OpenUBMC/iBMC 环境）

在 OpenUBMC 或 iBMC 系统中，当新增的 Lua 组件未能成功启动时，通常需要通过系统日志、启动流程检查和配置验证来定位问题。以下是详细的排查步骤和方法，帮助您确定Lua 组件未起来的具体原因。

:pushpin: 问题描述

在新增组件中编写代码并编译打包后，将组件升级到运行环境中，使用 lsmc 或 busctl --user tree 查看资源树时发现该组件未注册或未运行。无法确定是 Lua 代码逻辑错误、初始化失败，还是依赖缺失导致的问题。

:toolbox: 环境信息（示例）

  • 操作系统：Ubuntu 24.04（开发主机）
  • 软件版本：OpenUBMC 2509 / iBMC BMC-Kepler 系列
  • 硬件平台：基于 x86_64 架构的服务器 BMC
  • 脚本语言：Lua（版本 5.4.6），使用 Skynet 框架

:magnifying_glass_tilted_left: 重现步骤

  1. 使用 bingo new -n <component_name> -t application -l lua 创建新组件。
  2. 修改 service.json 添加所需接口依赖，执行 bingo gen 生成代码。
  3. 编译组件：bingo build，打包并升级至目标设备。
  4. 重启 BMC 或加载组件。
  5. 执行 lsmc 或 busctl --user tree 检查组件是否上线。
  6. 发现组件未出现，服务未启动。

:white_check_mark: 期望结果

能够准确查找到组件未能启动的原因，例如：

  • Lua 代码语法错误
  • main.lua 中 app.new 初始化失败
  • 缺少依赖服务（DBus 接口未提供）
  • 配置文件缺失或错误
  • MACA 启动检查失败触发回滚

:cross_mark: 实际结果（常见错误示例）

  • 组件进程未见，busctl --user tree 无对应节点。
  • 日志中提示 StartupCheck failed。
  • app.log 中显示 ctor 或 init 函数未被执行。
  • framework.log 提示某些 .service 文件缺失（如：bmc.kepler.firmware_mgmt not provided）。
  • 出现类似日志：[IOR: init.lua(185): [xxx] StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown。

:wrench: 尝试过的解决方案（无效或需补充）

  • :white_check_mark: 检查 service.json 是否添加了正确依赖
  • :white_check_mark: 确认 bingo gen 和 bingo build 成功执行
  • :white_check_mark: 检查 manifest.yml 是否加入组件依赖
  • :cross_mark: 仅查看 journalctl，未深入分析 app.log 或 framework.log
  • :cross_mark: 未启用 pcall 包裹初始化函数以捕获异常

:hammer_and_wrench: 正确排查方法与步骤

1. 检查关键日志文件

:white_check_mark: (1) 查看 app.log（核心日志）

路径：/var/log/app.log

cat /var/log/app.log | grep "your_component_name"
  • 若找不到日志，说明组件的 main.lua 未被加载。
  • 若有报错如 attempt to call field 'new' (a nil value)，说明 app = require("app") 失败或 app.lua 中未导出 new 函数。
  • 若 skynet.register("app") 后无后续打印，说明卡在 skynet 注册阶段。

:white_check_mark: (2) 查看 framework.log

路径：/var/log/framework.log

cat /var/log/framework.log | grep "LAUNCH\|your_component_name"
  • 查找是否有 [:00000006] bmc_core: LAUNCH 日志。
    • :cross_mark: 如果没有 LAUNCH 日志 → 表示框架未尝试启动组件，可能是：
      • manifest.yml 未正确声明组件
      • 编译包未安装
      • 启动控制文件（如 launch_control.json）中禁用了组件
    • :white_check_mark: 如果有 LAUNCH 日志 → 说明已尝试启动，应进一步检查 main.lua 是否触发异常。

:white_check_mark: (3) 检查 journalctl 系统日志

journalctl | grep your_component_name

用于查看是否有权限、路径或服务注册失败等系统级错误。

2. 确保配置文件存在且正确

以下配置文件缺失会导致组件无法启动：

文件 作用 常见错误
launch_control_00_ff.json 控制组件启动顺序和启用状态 :cross_mark: 缺失导致 init.lua 报错
mc_control.json 定义回滚策略 若设置为异常即回滚，可能导致反复重启
service.json 声明组件所需 DBus 接口 :cross_mark: 接口不存在或路径错误导致 StartupCheck 失败

:light_bulb: 重点检查：/opt/bmc/conf/launch_control_00_ff.json 是否存在。
多个上下文指出此文件缺失将导致 init.lua 初始化失败。

3. 验证组件启动依赖（D-Bus 服务）

组件通常依赖其他服务通过 StartupCheck 检查其可用性。

示例日志：

[init.lua(185): [firmware_mgmt] StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown]

这表示 BMC 启动过程中，firmware_mgmt 的服务未提供 .service 文件。

排查方法：

# 检查是否有该服务的 .service 文件
ls /usr/share/dbus-1/services/ | grep firmware_mgmt

如果缺失，则：

  • 该组件未安装
  • 安装路径错误
  • 服务注册未完成

4. 在 Lua 代码中使用 pcall 捕获异常

由于 Lua 中未被捕获的异常会导致协程退出且无明显提示，建议在 main.lua 中对关键初始化函数使用 pcall：

local ok, err = pcall(app.new)
if not ok then
    print("App.new failed: " .. tostring(err))
    -- 可写入日志
else
    print("Component started successfully")
end

:backhand_index_pointing_right: 此操作能暴露语法错误、nil 调用、模块加载失败等问题。

5. 确认是否被 MACA 检查机制触发回滚

MACA 是 BMC 中负责监控组件健康状态的守护进程。

常见现象：

  • 组件短暂启动，但很快被终止或系统回滚。
  • 日志中提示 continuously offline 5 time within 10 minutes。

解决方法（调试阶段）：

临时禁用回滚机制，在 /opt/bmc/conf/mc_control.json 中修改：

{
  "enable_rollback_on_failure": false,
  "enable_rollback_on_timeout": false,
  "enable_rollback_on_exception": false
}

然后 killall skynet 让系统重新加载，便于观察真实错误。

6. 确认代码是否生效

有时候虽然升级了包，但实际运行的仍是旧版本。

验证方式：

  • 登录设备后进入组件目录：
    cd /opt/bmc/apps/your_component_name/lualib/
cat app.lua
  • 确认代码已更新。
  • 检查是否有误将文件放在 mockdata、template 等非运行目录。

7. 使用 bingo 工具辅助调试

(1) 使用一键同步功能：

BMC Studio 支持“一键同步”，可将本地 Lua 代码自动部署到 QEMU 或远程设备，并重启服务。

:warning: 注意：仅支持 /opt/bmc/apps/ 下的 Lua 文件。

(2) 启用调试插件（VSCode + Skynet Debug Console）

  • 安装 VSCode Lua 插件（如 sumneko.lua 或 yinfei 轻量版）
  • 使用 skynet 的远程调试能力注入 Lua 脚本进行实时测试。

:clipboard: 总结：排查清单

检查项 是否完成 工具/命令
app.log 是否有组件日志 :white_check_mark: / :cross_mark: cat /var/log/app.log
framework.log 是否有 LAUNCH :white_check_mark: / :cross_mark: grep LAUNCH /var/log/framework.log
launch_control_00_ff.json 是否存在 :white_check_mark: / :cross_mark: ls /opt/bmc/conf/
service.json 依赖接口是否正确 :white_check_mark: / :cross_mark: 人工检查或 bingo check
是否使用 pcall(app.new) 捕获错误 :white_check_mark: / :cross_mark: 修改 main.lua
mc_control.json 是否关闭自动回滚 :white_check_mark: / :cross_mark: 修改 JSON 配置
main.lua 是否完整加载 :white_check_mark: / :cross_mark: 添加 print 或日志
.service 文件是否注册 :white_check_mark: / :cross_mark: ls /usr/share/dbus-1/services/

:blue_book: 参考资料

:white_check_mark: 结论

新建组件未起来的根本原因通常来自以下几类：

  1. 配置缺失（如 launch_control_00_ff.json 缺失）
  2. 依赖服务不可用（D-Bus 接口未注册）
  3. Lua 代码异常未被捕获
  4. MACA 启动检查失败 → 触发回滚
  5. 编译/部署流程错误，代码未真正生效

:white_check_mark: 推荐做法：

在 main.lua 中使用 pcall(app.new) 包裹初始化逻辑，并优先检查 app.log 和 framework.log，确认是否执行到组件入口。

通过上述系统化的排查流程，可精准定位组件启动失败的具体环节。

相关链接：

  1. 新增组件资源上树失败
  2. 25.03版本第一次maca组件检测会出现53组件只有7个起来，maca重新拉起后所有组件才起来
  3. 新增组件经验分享
  4. 【教学培训篇】新增组件
  5. BMC Studio 使用指导 | 文档中心 | openUBMC