bmc_time:ntp.lua日志刷屏

[yin (kunlun_yinmengyu)]

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

问题描述

上电静置场景下bmc_time NOTICE: ntp.lua(191)5分钟刷一条

2026-04-09 20:11:29.960935 unknown_service NOTICE: prefix.lua(99): eth2: parse and save prefix info, router_addr: fe80::529a:88ff:fe03:6306, prefix_len: 64 [repeated 5 times in 334s from 2026-04-09 20:05:56.427729 to 2026-04-09 20:11:29.960935]

2026-04-09 20:13:29.786817 bmc_time NOTICE: ntp.lua(191): update_extra_server is fd00:70:189:122::154 [repeated 146 times in 301s from 2026-04-09 20:08:28.328869 to 2026-04-09 20:13:29.786817]

2026-04-09 20:17:03.534753 unknown_service NOTICE: prefix.lua(99): eth2: parse and save prefix info, router_addr: fe80::529a:88ff:fe03:6306, prefix_len: 64 [repeated 5 times in 333s from 2026-04-09 20:11:29.960935 to 2026-04-09 20:17:03.534753]

2026-04-09 20:18:31.437337 bmc_time NOTICE: ntp.lua(191): update_extra_server is fd00:70:189:122::154 [repeated 146 times in 302s from 2026-04-09 20:13:29.786817 to 2026-04-09 20:18:31.437337]

2026-04-09 20:19:38.373663 power_strategy ERROR: scene_mgmt.lua(250): There is no frequency modulation system available

2026-04-09 20:19:57.366233 iam ERROR: init.lua(97): model.lua:1594 > iam_app.lua:612 > session_service.lua:823: The session has timed out, please log in again.

2026-04-09 20:22:35.424925 unknown_service NOTICE: prefix.lua(99): eth2: parse and save prefix info, router_addr: fe80::529a:88ff:fe03:6306, prefix_len: 64 [repeated 5 times in 332s from 2026-04-09 20:17:03.534753 to 2026-04-09 20:22:35.424925]

2026-04-09 20:23:32.978421 bmc_time NOTICE: ntp.lua(191): update_extra_server is fd00:70:189:122::154 [repeated 146 times in 302s from 2026-04-09 20:18:31.437337 to 2026-04-09 20:23:32.978421]

2026-04-09 20:28:04.269565 unknown_service NOTICE: prefix.lua(99): eth2: parse and save prefix info, router_addr: fe80::529a:88ff:fe03:6306, prefix_len: 64 [repeated 5 times in 329s from 2026-04-09 20:22:35.424925 to 2026-04-09 20:28:04.269565]

2026-04-09 20:28:13.893196 power_strategy ERROR: scene_mgmt.lua(250): There is no frequency modulation system available

2026-04-09 20:28:34.314369 bmc_time NOTICE: ntp.lua(191): update_extra_server is fd00:70:189:122::154 [repeated 146 times in 301s from 2026-04-09 20:23:32.978421 to 2026-04-09 20:28:34.314369]

2026-04-09 20:28:35.425966 storage NOTICE: rpc_service_subhealth.lua(191): start get drives estimatedlifespan diag info

环境信息

• 操作系统：[如 Ubuntu 24.04]

• 软件版本：[如 OpenUBMC2509]

• 硬件配置：[如 CPU、内存等]

重现步骤

1. [第一步]

2. [第二步]

3. [第三步]

期望结果

[您希望实现什么]

实际结果

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

尝试过的解决方案

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

分析结论

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

[ubmc_assistant (openUBMC_Assistant)]

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

结论总结

项目	结论
是否为故障？	否，属高频非错误日志刷屏，但存在运维风险。
根本原因	BMC 定期刷新备用 NTP 服务器配置，因网络不可达或配置未生效，导致 update_extra_server 被高频触发。
核心组件	bmc_time 模块中的 ntp.lua 脚本。
推荐处理方式	1. 使用 ipmcget -d ntp 检查状态； 2. 删除或更换无效的 ExtraServer； 3. 确保 NTP 服务可用； 4. 提交代码优化请求，限制日志输出频率或仅在变更时记录。

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

关于 bmc_time: ntp.lua 日志刷屏问题的分析与解决方案

---

问题描述

在上电静置场景下，bmc_time 组件持续打印如下 NOTICE 级别日志，每约5分钟刷一次：

bmc_time NOTICE: ntp.lua(191): update_extra_server is fd00:70:189:122::154 [repeated 146 times in 301s ...]

同时伴随 unknown_service 的 prefix.lua 日志刷屏。该现象虽未报错（日志级别为 NOTICE），但存在以下潜在影响：

• 频繁日志写入可能影响 Flash 寿命。
• 冲刷历史关键日志，降低可维护性与故障定位能力。

---

关键信息提取

从提供的上下文和检索结果中提取关键实体及行为：

信息项	内容
日志来源	bmc_time 组件，具体文件为 ntp.lua，行号 191
日志内容	update_extra_server is fd00:70:189:122::154
日志频率	每约 5 分钟重复一次
相关组件	BMCSet_NTPExtraServerAddr, ExtraServer, NTP
日志级别	NOTICE（非错误，但频繁触发）

---

根本原因分析

1. update_extra_server 的含义

根据知识图谱中实体关系：

• BMC → BMCSet_NTPExtraServerAddr：BMC通过此参数配置备用NTP服务器。
• ExtraServer → NTP：表示一个额外的NTP服务器地址。
• 日志中的 IPv6 地址 fd00:70:189:122::154 是一个私有网络地址，极可能是用户或系统配置的备用（extra）NTP服务器。

因此，日志 update_extra_server 表示：BMC正在尝试更新或确认其备用NTP服务器地址。

---

2. 为何会高频刷屏？

正常行为解释：

BMC 的 ntp.lua 脚本会定期检查并应用 NTP 配置，包括主/备服务器。即使未发生变更，也可能周期性地“刷新”配置状态，从而触发日志。

异常判断依据：

虽然 NOTICE 级别不表示错误，但高频重复（如每5分钟）刷新同一地址且无状态变化，表明系统可能陷入“确认-应用-再确认”的循环。

可能原因包括：

原因	依据
配置未持久化成功	BMC尝试设置 ExtraServer，但写入失败或未保存到持久化存储，导致每次轮询都视为“新配置”。
NTP服务不稳定或未启用	若NTP服务本身未开启，则无法完成同步，配置更新逻辑可能被反复触发。
网络层不可达该地址	fd00:... 地址虽配置，但网络不可达，BMC持续尝试连接并记录操作。
脚本逻辑缺陷（边缘情况）	在无变更时仍强制输出日志，缺乏“仅变更时记录”的判断逻辑。

参考文档 `#2《时间管理问题手册》指出：

• BMC 时间管理依赖 NTP 或 RTC；
• 可通过命令 ipmcget -d ntp 查看 NTP 状态；
• 若 NTP 未启用，则 BMC 不会从网络获取时间。

---

结合知识图谱进一步推断

• bmc_time 是制造模式使能（manufacture flag = True） 的组件，版本如 1.75.0。
• 它负责更新 NTP 配置、重启 NTP 进程、记录时间同步状态。
• 当前行为符合其功能范畴：监控和更新额外NTP服务器地址。
• 但此类日志“高频刷屏”不符合正常运维预期 —— 建议仅在配置变更时记录，而非定时轮询时重复记录。

---

解决方案建议

1. 检查并确认 NTP 配置状态

ipmcget -d ntp

输出样例如下：

{
  "Status": "enabled",
  "Mode": "unicast",
  "PrimaryServer": "192.168.1.10",
  "ExtraServer": "fd00:70:189:122::154",
  "Synchronize": "false"
}

重点关注字段：

• Status: 是否启用 NTP。
• Synchronize: 是否已同步成功。
• ExtraServer: 是否配置为 fd00:...。

若 Synchronize 为 false，说明虽配置但未同步成功。

---

2. 验证 ExtraServer 是否可达

手动测试 NTP 服务器连通性（需在 BMC 支持工具的前提下）：

/usr/sbin/ntpdate -uD fd00:70:189:122::154

• 若返回超时或不可达，则说明网络层面无法连接该地址，应考虑移除或更换为有效地址。
• 若无此命令，可通过 ping 或抓包分析 IPv6 连通性。

---

3. 清除或修改 ExtraServer 配置

若该 fd00:... 地址无实际用途，建议清除：

ipmcset -d ntp -v ExtraServer ""

或设置为有效地址：

ipmcset -d ntp -v ExtraServer <valid_ntp_ipv6>

根据知识图谱，若 BMCSet_NTPExtraServerAddr 为空，则 ExtraServer 会被设为 0.0.0.0（表示无效）。

---

4. 升级或修复 bmc_time 组件（长期方案）

当前行为属于非必要日志刷屏，应优化代码逻辑：

建议修改 ntp.lua 第191行附近逻辑：

if current_server ~= new_server then
    log("update_extra_server is " .. new_server")
    apply_config()
end

仅当服务器地址真正变更时才记录日志，避免无意义重复输出。

---

结论总结

项目	结论
是否为故障？	否，属高频非错误日志刷屏，但存在运维风险。
根本原因	BMC 定期刷新备用 NTP 服务器配置，因网络不可达或配置未生效，导致 update_extra_server 被高频触发。
核心组件	bmc_time 模块中的 ntp.lua 脚本。
推荐处理方式	1. 使用 ipmcget -d ntp 检查状态； 2. 删除或更换无效的 ExtraServer； 3. 确保 NTP 服务可用； 4. 提交代码优化请求，限制日志输出频率或仅在变更时记录。

---

附录：推荐排查命令汇总

功能	命令
查看 NTP 配置	ipmcget -d ntp
设置额外服务器	ipmcset -d ntp -v ExtraServer <address>
清除额外服务器	ipmcset -d ntp -v ExtraServer ""
测试 NTP 可达性	/usr/sbin/ntpdate -uD <server_ip>
查看当前时间	date, hwclock
检查日志刷屏情况	tail -f /var/log/app.log | grep ntp.lua

---

建议将此类非错误性日志刷屏纳入自动化测试观测点（参照“openUBMC通用观察点分享”），防止上线后影响系统稳定性与可维护性。

[zhangbaocun]

@yin

update_extra_server is

这个内部可以优化一下日志打印