ntpd 默认不立即校正大偏差时间，因启用“步进抑制”策略：偏差超128ms时仅slewing微调，避免突变引发日志错乱、事务异常等；需强制步进须用-g参数（仅首次有效）或改用chronyd。
为什么
不会立刻校正大偏差时间？
因为
默认采用“步进抑制”策略：当系统时钟与 ntp 服务器偏差超过 128ms，它会拒绝步进（step），只做缓慢 slewing（微调）。这是为避免突变时间导致日志错乱、数据库事务异常、定时任务重复触发等副作用。
常见错误现象：
启动后日志反复出现
，但几小时过去，时间仍差几分钟；
显示 offset 持续在 ±500ms 波动，不收敛。
真正需要步进时，必须显式启用
参数（仅首次启动有效）或改用
（已废弃）/
允许首次启动时容忍任意偏差并步进，但之后仍恢复 slewing 模式
若系统已运行且偏差 >128ms，
不会自动步进 —— 这不是 bug，是设计行为
如何安全地强制一次 NTP 步进校时？
用
替代
是当前主流方案，它默认支持可控步进，且更轻量、兼容 systemd。
实操建议：
停掉旧服务：
或
启用
：
立即步进同步：
（单次执行，不后台）
验证：
看
是否已对齐，
确认源可用
注意：
本质是临时实例+步进+退出，不会干扰正在运行的
守护进程。
是什么？修改它真能解决虚拟机时间漂移？
（Cluster Time Synchronization Service）是 Oracle RAC 环境中用于节点间时间协调的独立服务，**和系统级 NTP 完全无关**。它只在 RAC 集群中起作用，且默认仅在未检测到
或
运行时才激活。
常见误解：以为调高
的容忍阈值（如改
）就能“放宽时间检查”，实则徒劳 —— RAC 要求所有节点与外部权威时间源一致，
只是 fallback 机制，不能替代 NTP。
Oracle 文档明确要求：RAC 所有节点必须运行
或
，
仅作备用
修改
配置（如
）无法绕过 NTP 同步需求
虚拟机场景下，真正该做的是：禁用 hypervisor 的时间同步（如 VMware Tools 中关掉
），再由 guest OS 自行跑
容器或云主机里时间不准，别只盯着 NTP
容器共享宿主机内核时钟，但若宿主机本身没配好 NTP，容器必然不准；而某些云平台（如 AWS EC2）默认启用
，它基于 PTP，比传统 NTP 更精准，但需确认是否被覆盖。
排查路径：
先查宿主机：
看
是否为
，
是否在 active 状态
云环境优先用厂商服务：AWS 上
并确保
指向
容器内不要装
—— 它无法直接访问硬件时钟，且可能与宿主机冲突；应依赖宿主机时间同步
Kubernetes 节点时间不同步会导致
leader 频繁切换，这类问题必须从 node 层解决，而非 Pod 内补救
最常被忽略的一点：某些 CI/CD 流水线或测试镜像里，基础镜像自带
但默认 disabled，一启动就静默失效 —— 这类“默认关闭”的服务，得手动
并
。
ntpdntpdntpdtime slew +X.XXX sntpq -p-gntpdatechronyd -qntpd -gntpdchronydntpdsudo systemctl stop ntpdsudo systemctl stop systemd-timesyncdchronydsudo systemctl enable --now chronydsudo chronyd -q 'server cn.pool.ntp.org iburst'chronyc trackingSystem timechronyc sources -vchronyd -qchronydctssctssntpdchronydctssCTSS_TOLERANCEctssntpdchronydctssctsscrsctl modify resource "ora.ctssd" -attr "AUTO_START=1"syncTimeWithHostchronydAmazon Time Sync Servicetimedatectl statusSystem clock synchronizedyessystemd-timesyncdsudo timedatectl set-ntp truesystemd-timesyncd169.254.169.123ntpdetcdsystemd-timesyncdenablestart