chrony服务未启动导致系统时钟不同步，需手动启用并启动：sudo systemctl enable --now chronyd；配置错误、NTP源不可达、时间偏差过大（>1000秒）、容器/服务时钟隔离等也是常见原因。
chrony 服务没启动，timedatectl status 显示 System clock synchronized: no
这是最常见的情况：装了 chrony，但压根没跑起来。systemd 默认不自动启用它，得手动开。
实操建议：
- 运行
sudo systemctl enable --now chronyd，既开机自启又立刻启动 - 检查状态：
sudo systemctl status chronyd，确认是active (running) - 别只看
timedatectl status，它可能缓存旧状态；等 30 秒再查，或直接用chronyc tracking看实时同步情况 - 如果提示
Failed to start chronyd.service: Unit chronyd.service not found，说明包没装全，先sudo apt install chrony（Debian/Ubuntu）或sudo yum install chrony（RHEL/CentOS 7）
配置文件里写错了 NTP 服务器，chronyc sources -v 显示全是 ^?
^? 表示 chrony 根本连不上任何源，大概率是 /etc/chrony.conf 里的 server 行配错了地址、端口或用了已弃用的域名。
实操建议：
- 国内推荐用
server ntp.aliyun.com iburst或server time1.cloud.tencent.com iburst；iburst能加速初始同步，别漏掉 - 别写
server 127.0.0.1这种本地地址——除非你真在跑本地 NTP server - 如果公司内网有 NTP 服务器，确保防火墙放行 UDP 123 端口；
chronyc sources -v里看到^+或^*才算正常接入 - 改完配置必须
sudo systemctl restart chronyd，reload不生效
系统时间偏差太大，chrony 直接拒绝校时，日志报 Cannot step system clock
chrony 默认对 >1000 秒（约 17 分钟）的时间跳变会拒绝“步进”（step），只做缓慢调整（slew），导致校时极慢甚至卡住。
实操建议：
- 临时强制步进：运行
sudo chronyc makestep，它会立即把时间拉到正确值 - 永久允许大偏差步进：在
/etc/chrony.conf末尾加一行makestep 1 -1（表示对任意偏差都允许步进），再重启服务 - 注意：虚拟机刚从休眠恢复、或物理机 BIOS 时间严重错误时，大概率触发这个；别等它自己“慢慢追”，那可能要几小时
- 如果
chronyc makestep报错501 Not authorised，说明 chrony 配置了访问控制，需在 conf 中加cmdallow 127.0.0.1再重启
容器或 systemd 服务里读到的时间还是错的，date 和宿主机不一致
这不是 chrony 没配好，而是进程没继承系统时钟。典型场景：Docker 容器默认不共享宿主机的 /etc/localtime 和时钟状态；systemd 服务若设了 PrivateTmp=yes 或 ProtectSystem=strict，也可能隔离时间相关资源。
实操建议：
- Docker 启动时加
-v /etc/localtime:/etc/localtime:ro，并确保宿主机chronyd正常运行 - systemd 服务单元中，避免滥用
TimerRandomizedDelaySec或AccuracySec导致定时任务误判时间 - 检查是否启用了
systemd-timesyncd（它和 chrony 冲突）：sudo systemctl is-active systemd-timesyncd，若是 active，先sudo systemctl disable --now systemd-timesyncd - 最关键的：chrony 只管系统时钟，应用层是否用对了
clock_gettime(CLOCK_REALTIME, ...)而不是自己读/proc/uptime之类，那是另一层问题
date 命令看起来对了，不代表所有进程看到的是同一个时间。 
