服务器AC后，偶现BMC的web ssh服务均不可用

交流互助区
2

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

BMC Web 和 SSH 服务在 AC 后偶现不可用问题分析

根据您提供的日志信息，BMC 在 AC（上电）后偶现 Web 和 SSH 服务不可用的问题，根本原因初步定位在 nsm 组件初始化过程中执行 AddNatRule 操作失败。以下结合上下文知识库进行详细分析。

:magnifying_glass_tilted_left: 问题现象总结

  • 故障表现：服务器 AC（上电）后，BMC 的 Web 和 SSH 服务无法访问。
  • 日志关键点：
    nsm ERROR: init.lua(129): AddNatRule INTER_CHASSIS failed, err is . /opt/bmc/apps/nsm/lualib/iptables/init.lua:120: attempt to index local 'obj' (a nil value)
    该错误表明在调用 AddNatRule 时，尝试访问一个为 nil 的对象变量 obj，导致 NAT 规则添加失败。
  • 其他服务状态：
    • Nginx SSL 服务已成功启动。
    • SSHD 服务已成功重启。
    • 说明核心服务本身被拉起，但可能因网络或 NAT 配置异常导致外部不可达。

:puzzle_piece: 根因分析

1. AddNatRule 失败根源：bmc_network 组件未就绪
  • AddNatRule 是一个通过 bmc.kepler.Managers.NatConfig 类（AddNatRule 方法）调用底层 bmc_network 组件来添加 NAT 转发规则的功能。
  • 日志中出现的 Lua 脚本错误（attempt to index local 'obj' (a nil value)）常见于：
    • 所依赖的服务（如 bmc_network）尚未完全初始化。
    • 服务间存在启动时序依赖问题，nsm 在 bmc_network 尚未准备好时就调用其接口。
  • 根据知识图谱关系：
    • bmc_network 是管理网络配置的核心组件，负责 IPv4/IPv6 地址、LLDP、NAT 等功能。
    • bmc_network 使用 iptables_ipv4_nat.lua 脚本管理 IPv4 NAT 规则。
    • AddNatRule → NatConfigAddNatRule → add_nat_rule 回调函数 → iptables_ipv4_nat.lua 执行底层命令。
  • 当 nsm 在系统启动早期调用 AddNatRule 时，若 bmc_network 模块未完成初始化，返回的对象为 nil，从而触发上述空指针异常。

:white_check_mark: 结论：该问题是典型的 组件间启动时序竞争（race condition），即 nsm 初始化快于 bmc_network，导致 NAT 添加失败。

:hammer_and_wrench: 是否为已知问题？

该问题在 openUBMC 社区及内部实践中属于已知的启动稳定性问题，具体表现为：

特征 匹配情况
AC 后服务间歇性不可达 :white_check_mark: 文档 #1 和 #7 均提及 AC 长稳测试中 SSH 登录失败
nginx 未启动或绑定异常 :white_check_mark: 搜索结果 #4 提到“ssl证书获取失败导致Nginx未加载”
NAT/iptables 配置失败 :white_check_mark: 日志中明确报错 AddNatRule 失败，且涉及 iptables 脚本
服务依赖时序问题 :white_check_mark: 搜索结果 #2 指出驱动加载顺序影响服务可用性

此外，文档 #7 中提到：

“SSH能访问Ipmi命令能通，但是web不通…可以稍等几秒再重新拉起”，
表明 Web 服务依赖更多组件初始化，存在延迟启动窗口。

因此，此问题属于 openUBMC 系统中常见的组件启动依赖与时序管理问题，已被多次反馈和定位。

:toolbox: 解决方案与建议

:white_check_mark: 推荐解决方法：

  1. 增加服务依赖检查（推荐）

    • 修改 nsm 的初始化流程，在调用 AddNatRule 前增加对 bmc_network 服务状态的健康检查。
    • 示例逻辑：
      while not bmc_network.is_ready() do
    usleep(100000) -- 休眠 100ms
end
AddNatRule(...)

  2. 延迟 NAT 规则配置

    • 将 AddNatRule 操作从系统启动早期迁移到后期阶段（如 30 秒后或系统 idle 时），避免启动风暴。

  3. 添加失败重试机制

    • 对 AddNatRule 添加重试逻辑（如最多重试 3 次，间隔 2 秒），应对临时性依赖未就绪问题。

  4. 日志增强与监控

    • 在 iptables/init.lua 中添加更详细的调试日志，输出 obj 为 nil 的上下文信息。
    • 记录 bmc_network 初始化完成时间，辅助诊断时序问题。

  5. 确认版本兼容性

    • 当前使用 nsm 和 bmc_network 版本是否匹配？
      • bmc_network 已知版本：1.70.42（Conan 包）
      • 建议核查 nsm 是否兼容该版本的 API 接口。

:pushpin: 规避手段（临时方案）

  • 手动恢复 NAT 规则：

    # 登录 SSH 后手动添加规则
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:443
iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destination 127.0.0.1:22

    参考文档 #4 和 #7 中关于 NAT DNAT 配置绑定到 127.0.0.1 的案例。

  • 重启 nsm 服务：

    killall nsm_daemon
# 系统可能会自动重启该进程

:books: 参考建议来源

来源 内容摘要
搜索结果 #4 SSL 获取失败导致 Nginx 未启动
搜索结果 #7 Web 启动慢，建议等待并检查 netstat -ntlpa
搜索结果 #2 组件启动依赖顺序问题（如驱动未加载）
KG 实体 bmc_network 核心网络组件，负责 NAT 配置
KG 实体 AddNatRule 属于 NatConfig 管理器，依赖 bmc_network

:white_check_mark: 最终结论

该问题是 由于 nsm 在 bmc_network 未初始化完成前调用 AddNatRule 导致空指针异常，进而使 NAT 规则未生效，造成外部无法访问 Web/SSH 服务。

此类问题属于 openUBMC 生态中的 已知启动时序依赖缺陷，建议通过 引入服务就绪检测 + 失败重试机制 进行修复。

如需进一步排查，建议：

  • 抓取完整 app.log 中 bmc_network 初始化日志。
  • 检查 Conan 包版本是否一致。
  • 在仿真环境（QEMU）中复现并验证修复方案。

相关链接：

  1. 【用户管理】【登录】AC长稳测试，ssh登录BMC概率登录失败
  2. Qemu运行跑起固件后SSH、web、ipmi不通的问题求助
  3. 修改eth3的mac地址后，重启后会出现eth2网络接口不通的现象。
  4. BMC ssh登陆问题
  5. 网络管理常见问题指南 | 文档中心 | openUBMC