chrony 与 systemd-timesyncd 的取舍

发布时间:2025-12-20 20:28

## 两个选项的对比 systemd-timesyncd 是 systemd 自带的轻量同步器，只做客户端：向配置的上级时间源发起查询，逐步把系统时钟校准，部署上零依赖，装好系统就能用，配置项也少到一眼看完。chrony 是独立的时间服务套件，客户端与服务端一体：校准算法更精细，对网络波动与间歇性连接的适应性强，时钟被大幅拨动后的快速收敛能力也更强，还能让一台机器充当局域网内其他机器的时间源。前者的哲学是够用就好，后者的定位是又快又稳。 ## 各自的适用面 普通的单一应用服务器，对时间的要求停留在日志排序与证书校验能对上，timesyncd 完全胜任，少一个独立服务就少一分维护面。以下场景建议 chrony：数据库主从、分布式集群这类对时钟偏差敏感的部署，偏差要在毫秒级内收敛；网络环境不稳定、经常长时间离线的机器，chrony 的算法在恶劣条件下表现更好；想在内网自建时间源、让全部机器从内网同步的拓扑，服务端能力只有 chrony 有。 ## 落地示例 ``` timedatectl set-ntp true ``` 这一条开启 timesyncd，状态用 timedatectl 查看，输出里的同步状态与最后一次校时时间就是健康判据。切 chrony 则先关掉前者再装，配置里写上级源，内网拓扑里其他机器指向它即可，两套服务同时跑会互相拉扯，务必先停一套。 ``` systemctl disable --now systemd-timesyncd ``` ## 选择建议 默认机器用 timesyncd，敏感集群统一 chrony 并自建内网源，这几乎是不会错的组合。内网自建源还有个附带好处：全部机器的时钟偏差同源同向，排查跨机日志时的时间对齐误差更小。判断口径很简单：时钟偏差超过一秒才会出问题的业务，用哪个都行；问题在百毫秒级暴露的，直接上 chrony 别犹豫。顺云云服务器做接口签名这类时间敏感业务时，先检查同步服务的状态再上线，时钟同步是前提条件而不是可选项，出了签名校验失败再回头查时钟，就绕了远路。