sel time get的值和web os显示不一致

交流互助区
1

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

问题描述

  1. web端查看时间，ipmi sel time get以及os时间如图所示，web和os显示时间一致，但是与ipmi sel time get结果不一致

image
image496×120 7.07 KB

2.环境上开启ntp，但是同步失败，使用模式是从ipv4中获取

image
image348×164 4.72 KB

  1. ntpq -c as是空

image

  1. rtc读值如下

    image

有两个疑问，想请帮忙解答一下：

1）开启ntp但是同步失败后，时间是从哪里获取的

2）为什么sel time get的值和web os显示不一致，-vv用的是0x0a 0x48在闭源仓实现，值是从哪里取的

2

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

:white_check_mark: 总结

问题 原因 建议
NTP 开启但同步失败，时间从哪来？ NTP 开启后不使用 RTC，除非启用“NTP优先”策略；当前时间应为上电初始（来自 RTC 或手动设置） 检查 NTP 服务器可达性、启用“NTP优先”策略、验证 RTC 时间
sel time get 与 Web/OS 时间不一致？ SEL 时间由独立寄存器维护，未与 bmc_time 动态同步；尤其在 NTP 失败或服务异常时容易脱节 使用 ipmcget -d time 作为权威时间源，确认 bmc_time 服务正常，避免依赖 SEL 时间

:warning: 关键建议：

  • 在生产环境中应 确保 NTP 正常工作，否则时间偏差会影响日志审计、证书验证、任务调度等。
  • 若需高可靠性时间管理，应启用“NTP优先+RTC备份”策略（即 Custom_TimeSynchronizationPolicy=1）。

如有权限访问 bmc_time 服务日志或 ipmcd 闭源模块日志，可进一步定位同步断点。

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

关于 sel time get 值与 Web/OS 显示时间不一致及 NTP 同步失败的分析

根据您提供的信息，涉及 BMC 时间管理、NTP 同步状态、SEL 时间获取机制、RTC 时间读取等多个层面。以下将结合知识库中的 知识图谱（KG） 和 文档内容（DC），严格依据已有信息进行逐项解答。

:small_blue_diamond: 问题一：开启 NTP 但同步失败后，系统时间从哪里获取？

:white_check_mark: 结论：

当 NTP 启用但同步失败时，系统时间不会自动切换到 RTC，而是保持最后一次有效时间（可能是手动设置或上次同步结果），若从未成功同步，则可能依赖 RTC 或默认时间（如 1970 年）。

:pushpin: 依据分析：

  1. NTP 开启后优先级高于 RTC

    • 根据搜索结果《时间管理问题手册》：

      “NTP开启后只从NTP读取时间”
      ipmcget -d ntp 可查询 Status 是否为 enabled，若为 enabled，则系统仅尝试从 NTP 获取时间，不再主动使用 RTC 时间。

    • 若 NTP 未开启，系统才依赖 RTC 芯片时间作为主时间源。

  2. NTP 同步失败时的行为

    • 从 pmcget -d ntp 输出可见：
      Status            : enabled
Synchronize       : failed
      表示 NTP 功能已启用，但未成功与服务器同步。
    • 此时系统不会自动回退到 RTC 时间，除非配置了“NTP 优先，失败后使用 RTC”的策略。

  3. 时间同步策略支持“NTP优先”模式

    • 搜索结果《【已评审】配置导入导出项新增时间同步策略》中明确说明：

      支持两种策略：

      • 0: 仅 NTP（即使失败也不使用 RTC）
      • 1: NTP优先（失败后尝试同步 RTC）

      默认为仅 NTP 模式。

    • 当前环境中为 Mode: dhcpv4 且 Synchronize: failed，但没有证据表明已启用 “NTP优先” 策略，因此不会自动切换至 RTC 时间源。

  4. 初始时间来源可能是 RTC

    • 若 BMC 上电时 NTP 尚未同步成功，系统会从 RTC 芯片读取初始时间（《CSR配置字典之Time类》）：

      “系统启动时从RTC读取初始时间”

    • 但如果后续 NTP 启用但失败，该初始时间将被保留，直到手动干预或网络恢复。

  5. RTC 实际读取值与系统时间不一致

    • 您提供的 RTC 原始数据为：
      [134,7,4,3,5,20,39,56]
      这是通过 Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read 读取的底层二进制数据，需通过 SMC 协议解析为可读时间（例如通过 SMC_CMD_RTC_GET_TIME）。
    • 未见解析结果，无法判断 RTC 当前是否正确。
    • 若 RTC 时间错误，可能导致上电初始时间异常。

:white_check_mark: 综合结论：

当前系统时间来源于 BMC 上电时的 RTC 时间或最后一次手动设置的时间，NTP 虽已开启但未成功同步，且无回退机制启用，因此系统未更新时间，导致显示时间可能滞后或不准。

:small_blue_diamond: 问题二：为什么 sel time get 的值与 Web/OS 显示时间不一致？

:white_check_mark: 结论：

ipmitool sel time get 获取的是 BMC 的 SEL 日志时间（可能受 NTP/RTC/持久化影响），而 Web 和 OS 展示的是当前系统时间（受 BMC 时间同步机制影响）；两者时间基准不同，且存在协议实现与闭源模块行为差异，导致不一致。

:pushpin: 依据分析：

  1. sel time get 的实现机制

    • ipmitool sel time get 是 IPMI 标准命令，等价于调用 Get SEL Time Command (NetFn: 0Ah, Cmd: 48h)。

    • 搜索结果《问题咨询】IPMI设置sel time不生效》指出：

      “猜测：BMC实际存在实时同步RTC时间机制，会将设置时间进行覆盖？”

      “在V3以后，是不是增加了实时同步机制？不让修改BMC sel time时间？”

    • 说明在 openUBMC/v3 架构中，SEL 时间并非独立维护，而是与 BMC 系统时间绑定，一旦系统时间更新（如 NTP 成功），SEL 时间也会被覆盖。

  2. SEL 时间与系统时间的关系

    • 《CSR配置字典之Time类》中定义：

      SyncTimeStatus: 时间同步状态，用于监控 NTP 是否成功。
      系统应定期校准 RTC，并确保各时间源一致。

    • 《时间管理问题手册》提到：

      “NTP 开启场景下 ipmitool sel time set 会报错：Command not supported in present state”，
      说明当 NTP 开启时，SEL 时间被锁定，防止手动篡改。

  3. Web 与 OS 显示的时间来源

    • 搜索结果《CSR配置字典之Time类》明确：

      “时间信息管理，提供系统时间同步、RTC时间读取和NTP配置管理功能”

      Web 和 OS 显示的时间来源于 bmc_time 服务管理的 系统时钟（System Clock）。

      • 该时间由 NTP 或 RTC 提供，经 bmc_time 模块统一管理并对外输出。

  4. 时间显示不一致的可能原因

    项目 来源 特性
    sel time get IPMI SEL Time Register 固定时间寄存器，可能缓存旧值，不随系统时间动态刷新（尤其在 NTP 失败时）
    Web/OS 时间 bmc_time + NTP/RTC 动态更新，受 bmc_time 服务控制
    实际系统时间 System Clock 由 sync_time 服务维护
    • 若 bmc_time 服务因故障未运行或 NTP 配置异常，可能导致：
      • 系统时间已手动更新（如通过 UI 或命令行）
      • SEL 时间未同步更新
      • 导致两者显示偏差

  5. 关于 -vv 参数与闭源实现

    • ipmitool -vv 显示执行 0x0a 0x48（即 Get SEL Time 命令）
    • 该命令由 BMC 固件在闭源模块中实现（如 ipmcd 守护进程处理）
    • 若 bmc_time 服务未与 SEL 时间寄存器联动更新，会造成数据滞后。

  6. 日志显示与事实不符的问题

    • 例如日志中显示 1970，通常表示时间未初始化（《Event常见问题指南》）：

      “告警产生时间依赖环境时间”
      “复位后，BMC没有时间戳，因此显示为1970年”

    • 说明若 bmc_time 服务未成功启动或 RTC 失效，可能导致历史日志时间错乱。

:white_check_mark: 综合结论：

sel time get 返回的是 SEL 日志子系统的时间寄存器值，可能未与当前系统时间同步。
而 Web 和 OS 显示的是 bmc_time 服务管理的动态系统时间。
当 NTP 同步失败、服务未联动更新、或存在缓存延迟时，二者就会出现不一致。

:magnifying_glass_tilted_left: 建议排查步骤

:white_check_mark: 针对问题一（NTP 失败后时间来源）

  1. 确认时间同步策略

    # 查询当前策略（如果有接口）
ipmcget -d timesyncpolicy

    或检查是否支持 Custom_TimeSynchronizationPolicy=1（NTP优先，失败用 RTC）

  2. 检查 NTP 连通性

    ntpdate -q 192.168.1.254
ping 192.168.1.254

    当前 ntpq -p 显示已连接但无有效同步（offset=0，但 jitter 异常），可能服务器未响应。

  3. 检查 RTC 时间是否正确

    • 解析原始数据 [134,7,4,3,5,20,39,56]：
      • 通常前4字节为秒、分、时、日，按 BCD 编码
      • 示例：[134,7,4,3,...] → 134s, 7min, 4hr, 3day → 可疑（秒数超60）
    • 推荐使用标准接口查询：
      ipmcget -d time

  4. 查看 bmc_time 服务状态

    systemctl status bmc.kepler.bmc_time

    或检查日志是否有启动失败记录。

:white_check_mark: 针对问题二（时间显示不一致）

  1. 获取当前 BMC 时间

    ipmcget -d time

    查看是否与 Web/OS 一致。

  2. 对比 SEL 时间

    ipmitool sel time get
date                      # OS 时间

  3. 尝试手动同步（测试用）

    # 如果允许
ipmitool sel time set "04/04/2026 16:30:00"

    观察是否被允许以及是否持续有效。

  4. 检查日志确认时间服务行为

    journalctl -u bmc.kepler.bmc_time

    关键词：set bmc_time time_stamp, NTP sync failed, RTC read

:white_check_mark: 总结

问题 原因 建议
NTP 开启但同步失败，时间从哪来？ NTP 开启后不使用 RTC，除非启用“NTP优先”策略；当前时间应为上电初始（来自 RTC 或手动设置） 检查 NTP 服务器可达性、启用“NTP优先”策略、验证 RTC 时间
sel time get 与 Web/OS 时间不一致？ SEL 时间由独立寄存器维护，未与 bmc_time 动态同步；尤其在 NTP 失败或服务异常时容易脱节 使用 ipmcget -d time 作为权威时间源，确认 bmc_time 服务正常，避免依赖 SEL 时间

:warning: 关键建议：

  • 在生产环境中应 确保 NTP 正常工作，否则时间偏差会影响日志审计、证书验证、任务调度等。
  • 若需高可靠性时间管理，应启用“NTP优先+RTC备份”策略（即 Custom_TimeSynchronizationPolicy=1）。

如有权限访问 bmc_time 服务日志或 ipmcd 闭源模块日志，可进一步定位同步断点。

3

相差8H 通常是时区

IPMI标准命令不会结合时区

NTP同步失败后会继续使用RTC（1230版本）

4

相差8h能在闭源仓修改吗

5

8H是正常的不是bug

你可以通过ipmcget -d time 查询时区

也可以通过set 修改时区为0

7

现在看现象是ipmi结合了时区，bmc时间没有结合时区

image
image425×120 3.58 KB

image

8

os上发送timedatectl

OS本身也自带时区

ipmi命令只查时间戳

9

现在看现象是ipmitool 0x0a 0x48的结果结合了时区

image
image845×192 55.6 KB

10

是问题，修复时间待确认，闭源组件修改

11

你也可以使用IPMITOOL 18版本试试

18版本的话 应该和BMC时一致的

12

使用18版本也是带了时区

image
image436×156 7.09 KB

13

只根据版本判断不合适

可以已是否支持-Z参数为界

支持-Z的就会有这个问题

根据资料显示此机制为开源工具新规

但是留有-Z参数保持原逻辑不变

(感兴趣也可自行百度）