1230 SP1 补丁版本，长时间 AC 出现 SSH 无法连接

交流互助区
1

问题描述

长时间 AC 测试，出现 SSH 无法连接的现象，脚本判断条件：BMC ping 通，且能正常访问 redfish 后，使用 SSH 登录 BMC，登录失败，80 次出现一次

查看 security log 可见

2026-03-04T05:09:52.962673+08:00 2102315CBF10QC100040 sshd[5264]: error: get auth_mode failed
2026-03-04T05:09:54.476842+08:00 2102315CBF10QC100040 sshd[5440]: error: get auth_mode failed
2026-03-04T05:09:56.507441+08:00 2102315CBF10QC100040 sshd[5496]: error: get auth_mode failed
2026-03-04T05:09:58.604189+08:00 2102315CBF10QC100040 sshd[5534]: error: get auth_mode failed

查看 app.log 可见

2026-03-04 05:09:52.962124 native_code ERROR: uip_user.c(953): [uip user] Call method failed, Error name:org.freedesktop.DBus.Error.ServiceUnknown, Error message:The name bmc.kepler.iam was not provided by any .service files.

该时间点 sshd 发生了 coredump：

{1FA86B7B-496E-4D8F-8DC4-B39B11937CF6}

该时段伴有大量组件异常重启

{B197BA14-6B5A-421A-920F-1E9B949F7112}
{B197BA14-6B5A-421A-920F-1E9B949F7112}1678×873 163 KB

{2A8EA07D-72AF-4739-A9EB-DEE3B1337DDF}
{2A8EA07D-72AF-4739-A9EB-DEE3B1337DDF}1673×930 161 KB

一键日志（分卷压缩，去掉 txt 后缀解压）：

dump_info.zip.txt (993.6 KB)

dump_info.z03.txt (8 MB)

dump_info.z02.txt (8 MB)

dump_info.z01.txt (8 MB)

环境信息

1230 SP1 补丁版本

海力士闪存，但是未见典型 unexpected symbol 打印

2

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

:memo: 总结

项目 内容
问题类型 系统级时序竞争 + 资源残留
根本原因 AC 循环导致 shm 异常 → Skynet 重启 → IAM 未注册 → sshd 调用失败
触发频率 每 80 次 AC 出现一次，具有低概率高影响特性
建议优先级 :warning: 高（影响远程维护能力）
推荐措施 清理 shm + sshd 增加重试 + 服务启动依赖控制

建议将该问题提交至 BMC 固件团队，纳入下一版 SP2 或 Hotfix 进行修复，并在自动化测试套件中加入“AC循环后 SSH 登录成功率”作为关键验收指标。

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

关于1230 SP1补丁版本长时间AC后SSH无法连接的问题分析

根据您提供的详细日志和现象描述，现对“1230 SP1补丁版本，长时间 AC 测试出现 SSH 无法连接”的问题进行系统性分析与总结。

:pushpin: 问题概要

  • 问题版本：1230 SP1 补丁版本
  • 现象：在长时间 AC 测试（上电/掉电循环）过程中，约每 80 次出现一次 SSH 无法连接。
  • 判断条件：
    • BMC 可 ping 通；
    • Redfish 接口访问正常；
    • 但 SSH 登录失败。
  • 关键日志特征：
    • SSHD 报错：error: get auth_mode failed
    • 应用日志中出现：Call method failed, Error name=org.freedesktop.DBus.Error.ServiceUnknown, Error message: The name bmc.kepler.iam was not provided by any .service files
    • sshd 发生了 coredump。
    • 同时段系统中存在大量组件重启、消息队列延迟等异常行为。

:magnifying_glass_tilted_left: 根本原因分析

1. SSHD 认证失败的直接原因：get auth_mode failed

此错误来源于 sshd 进程尝试获取用户认证模式（auth_mode）时失败。结合错误堆栈及关联信息分析：

  • sshd 在执行 PAM（Pluggable Authentication Modules）认证流程时，会通过 D-Bus 调用 bmc.kepler.iam 服务来验证用户身份和权限。
  • 日志中明确指出：
    Call method failed, Error name=org.freedesktop.DBus.Error.ServiceUnknown, 
Error message:The name bmc.kepler.iam was not provided by any .service files
    这表明 IAM（Identity and Access Management）服务未正常运行或未注册到 D-Bus 总线上。

:warning: 结论：sshd 因无法访问 bmc.kepler.iam 服务而导致认证流程中断，引发 get auth_mode failed 错误并最终触发 coredump。

2. IAM 服务不可用的根本原因：组件大规模重启导致服务缺失

从日志可以看出，在 2026-03-04 05:14:30 左右，系统发生了以下异常：

（1）大量服务启动日志（LAUNCH snlua …）

[0000000b] om: LAUNCH snlua sd bus
[0000000e] ras: LAUNCH snlua fault_diagnosis/service/main
...
[00000002] interface: LAUNCH snlua bootstrap

这些是服务初始化阶段的典型日志。大量组件在同一时间“重新启动”，说明：

  • 整个 Skynet 框架（BMC 核心 Lua 运行时）经历了 异常崩溃或主动重启。
  • 此时 bmc.kepler.iam 服务尚未完成注册或尚未启动，导致其他服务（如 sshd）调用时出现 ServiceUnknown 错误。

（2）Skynet 消息队列严重延迟

Receiver Skynet message queue scheduling delay is 1120 ms (threshold: 500 ms)
  • 多次超过 1 秒的调度延迟，表明系统资源紧张、负载过高或存在死锁/阻塞。
  • 这种延迟可能引起关键服务启动超时、依赖关系断裂。

（3）共享内存（shm）问题

  • 日志中多次出现 shmlock 相关的警告，如：
    verify process pid=8005 failed, process is not alive, owner_pid=2377
  • 表明系统在执行 AC 循环时，存在 共享内存锁状态不一致 的问题，可能是旧进程残留或内存未正确释放，进一步引发服务启动失败。

3. 为何 SSH 恰好失败？Redfish 却正常？

服务 访问方式 是否依赖 IAM
SSH 命令行 + PAM + D-Bus :white_check_mark: 强依赖 bmc.kepler.iam
Redfish HTTP API，使用 token 或 session :cross_mark: 可缓存凭证，短时容忍 IAM 不可用
  • Redfish 接口可能已建立会话或使用本地缓存的 token，因此即使 IAM 短暂异常仍能响应请求。
  • 而 SSH 每次登录都需实时进行认证，一旦 IAM 不可访问，立即失败。

4. coredump 分析支持上述推论

  • 核心转储文件 core-ssh-6-20260228183921 确认了 sshd 进程崩溃。
  • 结合错误日志中的 D-Bus 调用失败，可判断为：在未处理 D-Bus 异常响应的情况下，代码尝试访问空指针或非法内存地址，导致段错误。

:puzzle_piece: 综合分析结论

层级 原因
表层现象 SSH 登录失败，提示 get auth_mode failed
直接原因 sshd 调用 bmc.kepler.iam 服务失败，D-Bus 返回 ServiceUnknown
根本原因 系统经历大规模组件重启，IAM 服务尚未注册完成，sshd 提前尝试连接导致失败
深层诱因 长时间 AC 测试中，共享内存（shm）状态混乱，导致 Skynet 框架异常重启，引发连锁故障

:light_bulb: 本质是一个 系统初始化时序问题：sshd 启动过早，早于 IAM 注册完成；而在 AC 循环中因 shm lock 问题频繁触发系统局部重启，放大了这一竞争条件的发生概率。

:white_check_mark: 建议解决方案

:white_check_mark: 1. 修复共享内存锁（shmlock）状态残留问题

  • 在 BMC 启动脚本中，增加对 /dev/shm 中 shmlock 相关共享内存段的清理逻辑。
  • 示例脚本：
    ipcs -m | grep $USER | awk '{print $2}' | xargs -I {} ipcrm -m {}
  • 或在内核模块加载/卸载时确保彻底释放 shm 资源。

:white_check_mark: 2. 增强 sshd 对 IAM 服务的容错能力

  • 修改 sshd 启动逻辑，在 D-Bus 调用前先检测 bmc.kepler.iam 是否已就绪。
  • 可采用以下策略之一：
    • 重试机制：若 IAM 不可用，等待几秒后重试认证，最多 3 次。
    • 启动依赖检查：通过 busctl list-names 或 systemctl is-active bmc-kepler-iam 判断服务状态。
    • 后台守护拉起：使用 systemd 的 Wants= / After= 机制确保依赖顺序。

:white_check_mark: 3. 优化 Skynet 组件启动顺序与健壮性

  • 在 launch_control.json 或相关配置中，定义 iam 服务优先于 sshd 启动。
  • 对关键服务添加健康检查与自动重启策略。

:white_check_mark: 4. 临时规避措施

  • 增加 SSH 登录脚本的 自动重试逻辑，建议间隔 5 秒，最多重试 3 次。
  • 人工操作时，可在 Ping 通 BMC 后等待 至少 1 分钟 再尝试 SSH 登录，避开初始化高峰期。

:paperclip: 相关参考（来自知识库）

  • bmc_core 是核心系统服务，负责协调包括 sshd 和 IAM 在内的多个子系统。
  • UniAutos.Wrapper.Api.RedFish.BmcRedFish.BmcRedFish 表明系统使用 Redfish API 与 BMC 通信，其稳定性与 D-Bus 架构解耦，故受影响较小。
  • openUBMC 社区版本已支持类似 autoreconnect 和服务依赖管理功能，可参考其设计。
  • Service Restart 机制允许服务最多重启三次，但 sshd 当前缺乏对依赖缺失的重试逻辑。

:memo: 总结

项目 内容
问题类型 系统级时序竞争 + 资源残留
根本原因 AC 循环导致 shm 异常 → Skynet 重启 → IAM 未注册 → sshd 调用失败
触发频率 每 80 次 AC 出现一次，具有低概率高影响特性
建议优先级 :warning: 高（影响远程维护能力）
推荐措施 清理 shm + sshd 增加重试 + 服务启动依赖控制

建议将该问题提交至 BMC 固件团队，纳入下一版 SP2 或 Hotfix 进行修复，并在自动化测试套件中加入“AC循环后 SSH 登录成功率”作为关键验收指标。

如需进一步分析 coredump 文件或 dump_info.zip 中的具体数据，请提供更详细的解析要求。

3

已修复，使用openssh 9.6p1-3.oe2403sp1-htrunk10_004 及以上的版本试试呢

4

这个是 openssh 的问题吗？

我看是报错 sshd 连不上 iam，难道不是和那堆组件异常重启有关，要定位为何组件异常重启吗？

2026-03-04 05:09:52.962124 native_code ERROR: uip_user.c(953): [uip user] Call method failed, Error name:org.freedesktop.DBus.Error.ServiceUnknown, Error message:The name bmc.kepler.iam was not provided by any .service files.

5

是openssh的问题，且已修复。sshd是由openssh提供的，错误发生在sshd里面。