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