1. 为什么我弃用ntpd改用chronyd从一次线上事故说起先说个真实经历。去年夏天我负责的一批CentOS 7.9机器出了个诡异问题每天晚上十一点半左右应用监控里会准时出现一批登录失败、会话过期的告警持续两三分钟又自动恢复。一开始大家怀疑是夜间批量任务抢占了资源查了一圈毫无头绪。直到有天深夜我盯着面板看突然发现告警时间点和服务器的硬件时钟跳变完全重合——那批虚拟机使用ntpd做时间同步但上游走的是公网NTP服务器延迟抖动一高ntpd的step修正直接把系统时间往前拨了大约40秒。会话过期、日志断层、告警错乱全是这40秒闹的。那次事故之后我把重点同步服务器全部切到了chronyd。说句公道话ntpd不是不好用它只是老了。作为1980年代设计出来的协议实现ntpd的算法在今天的网络环境下面临两个硬伤一是默认的同步策略偏保守时钟偏移需要多次轮询才能逐步收敛对虚拟机这种瞬间漂移的场景反应不够快二是它针对长时间稳定运行做了大量优化却不太适合现代环境下频繁的休眠、快照恢复、热迁移。而chronyd是RHEL/CentOS 8开始默认内置的NTP实现设计目标就是在不可靠网络和虚拟化环境下依然能保持高精度时间。聊几个直观的差别对比项ntpdchronyd默认安装CentOS 6/7自带CentOS 8/Ubuntu 20.04自带同步收敛速度慢往往需要几轮轮询快数秒内可修正较大偏移对网络抖动容忍度低抖动大时频繁调整高自动平滑频率漂移虚拟化环境适配一般需要额外配置好原生适配快照恢复配置文件/etc/ntp.conf/etc/chrony.conf日志/状态工具ntpq -pchronycNTP服务器模式支持支持且local stratum更灵活一句话总结如果你是物理机、网络稳定、对精度要求不高用哪个都行但只要你沾了虚拟机、云主机、容器化环境或者遇到过时间偶尔跳一下导致业务异常直接换chronyd省心得多。这篇文章我不打算只贴配置而是从协议原理、完整部署、状态体检到排障思路把我这一年多在几十台服务器上折腾chronyd的实操经验完整过一遍。文章里的命令和配置在CentOS 7/8、Rocky Linux、Ubuntu 18.04以上版本基本通用最后还会讲几个典型坑的排查链路都是我实际踩过的。2. NTP时间同步到底在同步什么报文计算逻辑和手动对时的区别很多刚接触时间同步的读者有个误解觉得NTP就是把本机时间和服务器时间对一下然后按差值改掉。实际根本不是这样。NTP的核心不是一次性校准而是持续测量并补偿时钟频率漂移——这一点直接决定了一台机器的时间精度能维持在什么水平。2.1 一次NTP请求里的四个关键时间戳NTP报文里面最关键的是四个时间戳这里用一个例子走一遍完整交互假设客户端C要跟服务器S对时T1客户端发出请求报文时记录下本机的发送时刻T2服务器收到请求报文时记录下服务器的接收时刻T3服务器发出响应报文时记录下服务器的发送时刻T4客户端收到响应报文时记录下本机的接收时刻这四次打点完全依靠各自主机的系统时钟。网络里一个完整的NTP请求大概长这样客户端C 服务器S | T1 请求报文 | |-------------------------------| 服务器在 T2 时刻收到 | | | T3 响应报文 | |-------------------------------| 客户端在 T4 时刻收到平时用tcpdump -i any udp port 123 -n抓包看到的NTP报文里那四个Timestamp字段就是上面说的T1到T4。如果某个字段全是0说明报文只走了半程比如客户端只发包没收包或者服务器地址不可达。2.2 偏移量offset和延迟delay的计算有了四个时间戳就能算出两个核心指标网络延迟 delay (T4 - T1) - (T3 - T2) 时间偏移 offset ((T2 - T1) (T3 - T4)) / 2为什么不直接拿T2 - T1当偏移量因为请求报文在网络上跑的那段时间你不知道是多少直接减会混入网络延迟。T4 - T1是客户端发出到收到响应的总耗时T3 - T2是服务器处理报文的耗时两者一减就是双向网络的净延迟。偏移量公式之所以取两侧的平均是基于一个假设请求和响应的网络路径延迟基本对称。如果不对称比如走了不同路由算出来的offset会有一定误差这也是为什么NTP精度受限的根源之一。chronyc tracking里的Last offset、RMS offsetchronyc sourcestats里的Offset就是这套逻辑算出来的结果。理解了公式你就明白一个事单次测出的offset不可靠真正的精度靠多次采样统计收敛。chronyd每次同步会保留最近若干轮数据用回归分析估算本地时钟的频率误差然后通过微调时钟频率来消化偏移而不是直接跳变。2.3 手动对时和持续同步是两码事这里有个重要概念要区分手动对时比如date -s、ntpdate -u直接把系统时间改成目标值。优点是立即生效缺点是粗暴可能引起时间回拨。回拨对数据库事务、消息队列、分布式锁的伤害很大日志时间错乱都算轻的。很多教程让你用ntpdate做同步生产环境我强烈不建议。持续同步chronyd/ntpd先估算偏移再通过逐步调整时钟频率让时间和服务器对齐。正常情况下是平滑slew只有偏移大到超过阈值时才选择直接step跳变。这种方式对业务无感日志时间线连续。chronyd的平滑slew能力正是我在第一节说虚拟化场景比ntpd好用的核心原因。chronyc tracking里有一行叫System time如果值是0.000012341 seconds fast of NTP time这类微小正值说明系统正通过微调频率保持同步而不是来回改系统时间。这种写法就是让时间以正确的速率往前走而不是把时间拽回来。3. 从安装到配置落地chronyd完整部署步骤这一节直接给完整可复制的操作。环境以CentOS 7.9和Rocky 9为例Ubuntu系的差别我会在括号里标注。3.1 安装与初始状态确认CentOS/RHEL系列# 查看是否已安装 rpm -qa | grep chrony # 未安装则执行 yum install -y chrony # 或 CentOS 8/Rocky 9 使用 dnf dnf install -y chronyUbuntu/Debian系apt update apt install -y chrony装完先看一眼版本和当前时间状态chronyd --version timedatectltimedatectl输出中关注三行Local time本机时间Universal timeUTC时间NTP service: active是否启用了NTP服务如果NTP服务不是active需要执行timedatectl set-ntp trueUbuntu上尤其常见因为systemd-timesyncd会抢占端口。另外提醒一句chronyd和systemd-timesyncd不能同时启用两个都监听UDP 123端口会直接冲突。Ubuntu上如果chronyd起不来先查这个。3.2 chrony.conf关键配置项拆解主配置文件在/etc/chrony.conf我贴一份生产环境实际在用的模板然后逐行解释# 上游时间服务器iburst表示首次启动时快速连续发送报文以快速收敛 pool 2.centos.pool.ntp.org iburst pool ntp.aliyun.com iburst # 允许本机作为时间服务器给内网其他机器提供时间同步 # 这里建议只对明确的内网网段开放不要写 allow all allow 192.168.0.0/16 # 即使无法联系上游也宣布本机为时间源stratum层级设高一点 local stratum 10 # 平滑修正初始1秒内误差直接step修正后续误差超过1秒也step makestep 1 3 # 时钟频率漂移文件存储路径 driftfile /var/lib/chrony/drift # 日志相关 logdir /var/log/chrony log measurements statistics tracking逐项说为什么这么写。pool和server的区别pool会解析域名拿到多个IP地址自动作为多个源server则固定配置单台服务器。生产环境我更推荐pool加iburst。iburst的意思是服务启动后立刻连续发4个报文而不是等一个正常的轮询间隔这样能在几秒内完成初步同步。第一次配置chronyd的机器如果没有iburst可能要等一两分钟才能看到状态变成*有了它基本几秒搞定。allow后面的网段是谁可以来问我时间。默认不写allow时chronyd只同步上游、不接受客户端请求。如果你要做内网NTP服务器让一堆机器都从你这儿取时必须写allow。local stratum 10的逻辑是万一上游全挂了chronyd依然对外宣称自己是有效时间源但stratum值较高表示我这个源优先级很低避免在正常状态下被客户端优先选中。makestep 1 3是很多Linux默认也没有特别强调、但你最好理解的参数。格式是makestep 阈值 触发条件次数含义是当偏移量超过1秒且已经发生了3次每次轮询算一次就直接step跳变不继续slew了。为什么要设这个因为机器从快照恢复或者休眠唤醒后时间可能偏了几十分钟甚至几分钟这时候还坚持slew慢慢调业务早挂光了。直接step是最干净的处理。前3次轮询内如果偏移小于1秒会尝试slew平滑修正这也是对正常场景的保护。driftfile指定频率漂移文件的位置。这个文件记录本机晶振与真实时间的频率偏差相当于给chronyd一个预热记忆。机器重启后chronyd读取这个文件就不用从零开始估算频率误差了。生产环境这个文件我见过因为权限不对写入失败的情况所以要确保/var/lib/chrony/目录对chrony用户可写。最后log measurements statistics tracking是打开详细运行日志。平时不开也行但排障时这些日志是救命稻草。下文会讲怎么看这些日志。改完配置重启并设置开机自启systemctl restart chronyd systemctl enable chronyd3.3 配置一台内网NTP客户端如果你的机器不走公网NTP只从内网NTP服务器同步配置更简单# /etc/chrony.conf server 192.168.1.10 iburst # 客户端不需要allow不需要local stratum makestep 1 3 driftfile /var/lib/chrony/drift客户端配置里的server直接指向内网NTP服务器IP。有一个坑内网客户端不要写pool。pool是给域名用的填IP时用server语义更清晰也避免pool做一些额外的解析逻辑。当然填IP的时候pool也能解析只是没必要。启动后客户端怎么确认同步成功看下一节。4. 用chronyc给服务器做体检确认时间同步真的没问题装完chronyd只是开始更关键的是知道它当前状态是不是真的健康。很多新手看完Active: active (running)以为就完了其实那一行只能说明进程活着不能说明时间在同步。真正要看的命令是chronyc。4.1 chronyc tracking输出逐字段解读chronyc tracking是查看本机同步状态的最高频命令示例输出Reference ID : 203.107.6.88 (ntp.aliyun.com) Stratum : 3 Ref time (UTC) : Wed Jul 12 09:23:45 2024 System time : 0.000012345 seconds fast of NTP time Last offset : 0.000024567 seconds RMS offset : 0.000031234 seconds Frequency : 12.345 ppm slow Residual freq : 0.002 ppm Skew : 0.005 ppm Root delay : 0.023456 seconds Root dispersion : 0.001234 seconds Update interval : 1024.1 seconds Leap status : Normal逐行说我关心的重点Reference ID当前同步的上游源IP和主机名。如果显示(0.0.0.0)或者(local)说明当前没有从外部同步。Stratum本机层级。它等于上游源的stratum加1。对于互联网公共NTP服务器一般stratum是2或3那你的机器就是3或4。如果显示10说明走了local stratum 10的兜底配置此时大概率上游不可达需要立刻检查网络。System time本机与NTP时间的偏差符号表示快/慢。绝对值在几十毫秒内都算正常如果持续几秒甚至更大说明同步有问题。Last offset上一次同步后的残余偏差。这个值越小说明当前同步越准。RMS offset历史统计的均方根偏差反映同步的整体稳定性比Last offset更有参考价值。长期看如果RMS offset在个位数毫秒以内说明环境稳定。Frequency本机晶振的频率误差单位ppmparts per million百万分之一。12.345 ppm slow表示本机晶振每天慢约1.06秒12.345×86400/1e6。有这个数值撑着chronyd才能通过提前补偿让你的系统时间保持准确而不是靠反复改系统时间。Root delay和Root dispersion到根时间源的总网络延迟和总分散度。值越大说明链路越长或上游质量越差。Leap status闰秒相关状态。Normal就对了Insert/Delete表示上游在通报闰秒事件一般不用管。我自己给团队的验收红线是指标合格线Reference ID非空且不是local必须Stratum≤5System time绝对值 1秒RMS offset长期 50msLeap statusNormal满足这些这台机器的时间服务才算能用。如果System time到秒级或者Stratum显示10就先别急着上业务往下看排查思路。4.2 sources和sourcestats上游源的健康度判断chronyc sources -v输出示例210 Number of sources 2 MS Name/IP address Stratum Poll Reach LastRx Last sample ^* ntp.aliyun.com 2 6 37 4 -223us[ -223us] /- 15ms ^- 2.centos.pool.ntp.org 2 6 37 3 -231ms[ -231ms] /- 56ms每行的第一个字符是关键标记*当前正在使用的同步源候选源通过条件检查可被选为主源-被排除的源比如差距过大?尚未建立通信x被视为虚假源falseticker通常是网络异常导致上面例子中aliyun的源被选为当前主源*centos pool的源虽然在工作Reach非0但因为延迟明显更高231ms对比223us被当作备用而不是主源。Reach字段是最近8次轮询的命中情况用八位二进制表示37的二进制是100101说明最近8次有几次成功。如果Reach是0说明最近都没通信成功要怀疑网络或者防火墙。chronyc sourcestats -v多了统计视角210 Number of sources 2 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ntp.aliyun.com 18 10 36m -0.451 0.036 -6us 12us 2.centos.pool.ntp.org 18 10 36m -0.464 0.041 -21us 13usNP是采样点数Span是跨越时间范围Frequency是该源的频率偏差估算Offset是估算偏移均值Std Dev反映采样偏差的离散程度。不用看得太精细你只需要注意一点主源和其他源之间的Offset差异不要过大。如果两个源一个说偏移5ms另一个说-200ms说明拓扑或路径有明显不对称最终时间准确度会打折扣。4.3 常用运维命令小结除了上面两个这几个命令也值得掌握# 查看当前时间源及同步状态简短版 chronyc sources # 强制重新选择同步源 chronyc reselect # 手动发起一次同步不需要改makestep阈值 chronyc makestep # 查看当前所有客户端来源当你作为NTP服务器时 chronyc clients # 查看本机NTP端口监听状态 ss -ulpn | grep 123chronyc makestep这个命令在排障时特别有用。比如你手动改了系统时间比如date -s临时修正想让chronyd快速重新对齐可以执行chronyc makestep它会立即应用当前估算的偏移量而不是等下一个轮询周期。5. 环境选型对比自建NTP服务器 vs 公网NTP vs 云厂商NTP前面讲的都是怎么让chronyd干活但还有一个经常被忽略的问题上游时间源从哪里来这一步选错后面精度和稳定性都无从谈起。5.1 三种常见方案及适用场景方案优点缺点适用场景直接用公网NTP池pool.ntp.org、阿里云、腾讯云公共NTP部署简单零成本受公网抖动影响跨运营商延迟不定单机或少量服务器对精度要求不高自建内网NTP服务器上游指向公网NTP内网机器延迟低、精度稳客户端配置简单需要一台长期运行的服务器做NTP Server上游挂了要兜底批量服务器/虚拟机内网环境云厂商内网NTP地址如阿里云、AWS的169.254.169.123等延迟极低稳定不做额外兜底也安全仅限云厂商VPC内网络可达云上批量ECS第二种方案是最常见的企业做法一台或几台物理机/低负载虚机做NTP服务器客户端都指向它。这台NTP服务器本身用chronyd从公网NTP源同步同时开启allow给内网放行。内网客户端的同步延迟通常只有零点几毫秒比公网动辄几十毫秒好太多。5.2 自建内网NTP服务器的完整配置示例假设内网NTP服务器IP是192.168.1.10上游用阿里云公共NTP和ntp.ntsc.ac.cn国家授时中心做冗余。服务器端/etc/chrony.conf# 上游选两个不同服务商的公共NTP避免单一服务商故障 server ntp.aliyun.com iburst server ntp.ntsc.ac.cn iburst # 只对办公网和生产网段开放 allow 192.168.1.0/24 allow 10.10.0.0/16 # 上游不可达时向客户端宣告本地层级 local stratum 10 # 关键不要把这台NTP服务器同时作为客户端频繁调整避免把上游抖动传给下游 minpoll 6 maxpoll 9 makestep 1 3 driftfile /var/lib/chrony/drift两台服务器都开着NTP谁当服务器谁当客户端要角色分明没有集群协商机制。如果你建了两台NTP服务器做冗余客户端可以配置两个server轮流尝试但我不建议在同一批客户端里让它们各自随机选上游——那样会导致不同机器时间基准不一致。5.3 公共NTP源怎么选公共NTP源的地址经常变我实际用过觉得靠谱的ntp.aliyun.com国内延迟低解析出来通常是就近IP第一优先级ntp.ntsc.ac.cn国家授时中心权威性高国内可达pool.ntp.org全球NTP池自动分配但国内网络延迟不稳定各大云厂商的内网NTP地址比如AWS的169.254.169.123阿里云VPC也有对应的内网NTP地址这个对云上实例精度最好配置上游时不要写太多源。有些新手喜欢叠七八个server结果chronyd为了在众多源之间做复杂协商收敛反而更慢。两个到三个足够一个主用一个备用。上面配置里我特意写了minpoll 6和maxpoll 9含义是最小轮询间隔64秒、最大间隔512秒这样NTP服务器本身的请求频率适中不会对上游造成压力也不会因为频繁请求在公网上引入更多抖动。6. 我在生产环境踩过的坑排查链路与修复过程工具再好用不对一样翻车。这一节把我在生产环境踩过的坑整理成完整排查链路而不是直接给答案目的是希望读者下次遇到类似问题知道从哪里入手。6.1 坑一虚拟机时间总是漂移同步不收敛现象ESXi上的CentOS 8虚机chronyc tracking显示System time经常在几百毫秒到几秒之间波动RMS offset长期下不来。排查链路先看宿主机时间是否正常date -RESXi shell里执行。结果宿主机时间与真实时间差了2分钟。虚机在启动时从宿主机继承了初始时间但运行过程中ESXi的时钟模型和客户机时钟有偏差而且ESXi默认的guest OS时间同步策略和chronyd的调整会互相干扰。查看虚机CPU模型grep hypervisor /proc/cpuinfo。确认是虚拟化环境后我意识到chronyd需要额外关注maxslewrate。默认情况下chronyd的slew速率有限大偏移时倾向step。但ESXi的平台时钟模型更复杂如果chronyd一直在做微小slew会因为宿主机的计时偏差而永远追不上。修复方案先在/etc/chrony.conf里明确设置maxslewrate 1000允许最大slew速率千分之一同时检查ESXi层面的时间同步设置。两种情况只留一种要么在ESXi虚机设置里勾上同步客户机时间要么在客户机里跑chronyd二者同时开就会有竞争。我的建议是客户机优先用chronydESXi那层关掉自动同步。实际执行后RMS offset从几百毫秒降到10毫秒内。这个坑的教训是虚拟化环境下宿主机的时钟模型和客户机的NTP服务必须在同一频率上运作否则你的chronyd再努力也没用。6.2 坑二防火墙放行了UDP 123为什么还是同步失败现象新部署的Red Hat 8机器chronyc sources所有源都显示?Reach为0但本机防火墙已经放行了udp 123。排查链路先确认本机chronyd监听正常ss -ulpn | grep 123输出存在说明监听没问题。本机抓包看NTP请求是否发出tcpdump -i any udp port 123 -n -c 10看到请求发出去了但没有收到任何响应。问题定位到上游防火墙。很多云安全组除了要放行入方向的UDP 123还要确认出方向的UDP 123没被安全策略挡掉。更隐蔽的是有些云安全组对UDP协议的支持不如TCP长时间无连接的UDP报文可能被中间设备静默丢弃。我当时排查到这一步用nc -u -z -w 2 ntp.aliyun.com 123做UDP连通性测试结果超时确认确实不通。最后发现是计费安全组里出方向规则只放行了TCP协议。加了一条出方向UDP 123放行规则后chronyc sources立刻显示*。这个坑的通用排查思路是NTP是UDP 123做连通性测试一定要用UDP而不是TCP。很多运维习惯性telnet ip 123TCP能通不代表UDP通这个测试结果会误导人。6.3 坑三重启后时间跳回几个月前chronyd启动失败现象一台Ubuntu 20.04机器接近半年没用开机后系统时间显示的是半年前的时间systemctl status chronyd显示启动失败。排查链路查看chronyd日志journalctl -u chronyd -n 50核心报错是chronyd: Could not open /var/lib/chrony/chrony.drift: Permission denied。检查目录权限ls -la /var/lib/chrony/发现目录属主是root而chronyd以chrony用户运行没有写权限。这就导致drift文件写不进去服务启动直接失败。修复chown -R chrony:chrony /var/lib/chrony然后systemctl restart chronyd时间逐步收敛。这个坑虽然简单但背后有个经验点值得说drift文件的权限问题平时不会暴露因为默认安装时装机会把目录权限配好。但如果你做过系统迁移、手动拷贝过/var/lib或者用容器镜像打包过环境权限经常被带歪。打包镜像时最好显式跑一遍chown chrony:chrony /var/lib/chrony。6.4 坑四maxdistance和maxslew参数不显眼但在某些业务场景里很关键这个坑是我在金融类业务场景遇到的。业务方要求系统时间只能平滑slew不能step跳变因为一旦跳变分布式事务里依赖时间戳的排序就会乱掉。但chronyd默认允许step跳变配置了makestep 1 3。如果源和本机时间相差很大chronyd即使走slew也会因为偏移量过大而被迫step。排查链路业务反馈系统时间跳了一下查看journalctl -u chronyd发现日志里有System clock wrong by -3.2 seconds, step。说明确实是step修正。查看chrony.confmakestep 1 3策略在生效。此时我需要改成禁止step只用slew同时限制能接受的最大偏移范围。修改配置# 允许的偏移量上限超过就继续slew而不是step maxdistance 1.0 # 禁止step只允许slew makestep 0 -1makestep 0 -1的含义是阈值设为0秒、触发条件设为-1次。当条件次数是负数时chronyd永远不会step只做slew。maxdistance 1.0指的是根距离超过1秒时不再同步防止上游源不可靠时仍然把不靠谱时间应用进来。验证重启chronyd后观察chronyc tracking确认Leap status和System time稳定日志里不再有step字样。这个配置的代价是如果时间偏移真的非常大比如几分钟chronyd需要很长的时间才能收敛。所以这种配置只适合对时间变化极其敏感的业务不能盲目套用。一般业务我建议保留makestep 1 3的开箱默认。6.5 坑五Windows机器和Linux机器互相看到的时间不一致这块不算chronyd的坑但排查过程中经常被一起拉出来问几台CentOS机器用chronyd同步到内网NTP服务器时间看起来都挺准但有一批Windows Server 2019的机器显示的时间总是差8小时。排查链路先在Linux侧确认date -u显示UTC时间正常chronyc tracking的System time正常。说明Linux这边没问题。在Windows机器上执行w32tm /query /status发现本机时间确实是UTC8但配置的NTP服务器返回的是UTC时间Windows偏好用本地时间显示。看起来差8小时其实是正常的时区差异不是同步故障。真正要检查的是Windows的时区设置而不是NTP服务器地址。控制面板把时区设为北京时间后显示就正常了。这个坑提醒我时间同步和质量问题要先分开绝对时间准确性和显示时区两层很多排查耗时都浪费在把时区显示问题当成同步问题上。7. 关于chronyd监控和日常巡检的几条建议时间同步这件事最怕的不是出故障而是故障发生之后没人知道。正常情况下一台服务器的时间偏移不会大到影响业务的成都但一旦积累久了数据库间隙锁、日志顺序错乱、证书校验失败这些问题会陆续冒出来。所以监控和巡检一定要跟上。建议把下面几条纳入常规巡检脚本#!/bin/bash # 检查chronyd是否在运行 systemctl is-active chronyd || echo chronyd is not running # 检查当前是否有同步源 chronyc sources | grep -q ^\^\* || echo no active sync source # 检查时间偏移超过阈值告警 system_time$(chronyc tracking | awk -F: /System time/{print $2}) echo Current system time offset: $system_time阈值建议在几秒级别就告警不用等到业务出问题才去查。我一般设5秒为warning30秒为critical。另外提一个日常容易被忽略的点chronyd的日志文件不要设太大。长期运行/var/log/chrony/下的measurements.log和statistics.log会持续增长。对于一般服务器建议配合logrotate按周轮转保留4周即可。如果不设置日积月累有可能把/var分区写满这个坑我见过不止一次。再给一个经验在大版本升级或者内核升级后务必重启一次chronyd。Linux内核的时间管理接口偶尔会有变化旧的chronyd进程可能没有自动适配新的接口重启一下最省事。8. 最后分享两个我实际用了很久的小技巧第一个是chronyc clients。如果你做了内网NTP服务器想看看谁在问你要时间、多久问一次这个命令比抓包直观得多。它可以列出每个客户端的IP、最后一次访问时间、发送次数。有时候为什么这台机器时间还是不对的答案就在这个输出里——它的请求根本就没到你这里来。第二个是chronyc manual它适用于没有网络环境、只能靠人工抄录参考时间的场景。比如某台物理机完全隔离了外网你每天定时去机房看一次标准时间就可以把它喂给chronyd做手动校正。正常情况用不到但在地市级机房、涉密网络环境里这是一个很多资料都不讲但确实存在的功能。命令很简单chronyc manual on chronyc manual add 12:34:56chronyc manual add后面的参数填你读到的标准时间。它会把这个参考值纳入估算而不是直接改系统时间避免把人工读数误差引入得太多。关于chronyd NTP同步我目前能想到的实操细节就这些。如果你也遇到过什么奇怪的时间同步问题或者有更好的参数调优经验欢迎交流。