导读:本期聚焦于天马创作的《RHEL中chrony无法同步NTP怎么办?排查与修复指南》,敬请观看详情。chrony服务明明在运行,但执行chronyc tracking却发现时间偏差持续扩大,系统日志里反复出现无法连接到NTP服务器的报错。这种情况在RHEL环境中并不少见,尤其是防火墙策略、SELinux上下文或者网络配置变更之后。文章从chrony的配置检查、服务状态诊断、网络连通性验证三个层面入手,先解释chrony与NTP交互的基本原理,再给出systemctl与chronyc命令的排查思路,并对比手动同步与自动同步的区别。还整理了常见报错信息与对应解决方法,例如无法绑定端口、源不可达、时间跨度超限等问题,帮助运维人员快速定位chrony无法同步NTP的根因并恢复时间同步。

在RHEL系统中,chrony是默认的时间同步服务,负责通过NTP协议与远程时间服务器校准系统时钟。如果chrony无法完成同步,系统时间可能逐渐漂移,进而影响日志记录、证书校验、分布式任务调度等。遇到chrony无法同步NTP的情况时,不要直接重启服务了事,而应按照服务状态、配置、网络、SELinux、日志的顺序逐步排查。本文会给出完整的诊断路径和常见解决方案。

RHEL中chrony无法同步NTP怎么办?排查与修复指南

一、检查chronyd服务状态与基础配置

chrony由两个核心组件组成:chronyd守护进程负责与NTP服务器通信并调整时钟,chronyc是命令行管理工具。确认chronyd是否正常启动是第一步。如果服务处于失败状态,需要先通过systemctl查看具体报错,而不是盲目重启。

systemctl status chronyd
systemctl is-enabled chronyd

如果服务在运行但时间仍然不同步,则进一步检查配置文件。RHEL的chrony主配置文件位于/etc/chrony.conf。常见的配置错误包括server行写错、没有配置任何时间源,或者iburst参数缺失导致同步速度慢。可以使用grep命令快速过滤有效配置行。

grep -E '^(server|pool|allow|deny)' /etc/chrony.conf

其中server或pool指定上游NTP服务器。RHEL默认可能使用pool 2.rhel.pool.ntp.org iburst,如果网络环境限制无法访问公网NTP,就需要改为内部NTP服务器地址。修改配置后必须重启chronyd或使用chronyc reload让配置生效,否则改动不会自动应用。

二、排查网络连通性与防火墙规则

NTP协议默认使用UDP 123端口。客户端向服务器发送请求时,本地源端口通常是随机高位端口,但目标端口固定为123。如果防火墙只放行了出站TCP而没有放行UDP 123,或者默认拒绝出站UDP,同步请求就会超时。RHEL中使用firewalld管理防火墙时,可以检查当前生效区域和服务。

firewall-cmd --list-all
firewall-cmd --permanent --add-service=ntp
firewall-cmd --reload

在RHEL 8/9中,ntp服务默认与UDP 123端口关联。如果使用iptables或nftables,则需要确认规则是否存在。除了防火墙,还要检查SELinux是否阻止chronyd访问网络。可以通过audit2why查看SELinux告警,或者临时执行setenforce 0测试是否恢复正常。如果临时关闭SELinux后同步成功,说明需要调整SELinux策略或布尔值。

另外,如果系统位于NAT环境或存在网络ACL,也需要确保UDP 123双向可达。可以使用以下命令测试到目标NTP服务器的UDP连通性。如果没有nc,可以用chronyc的burst选项配合tcpdump抓包分析,观察是否有响应报文返回。

nc -u -v 192.168.1.10 123

三、利用chronyc与系统日志定位根因

chronyc提供了多个诊断命令。sources可以列出所有配置的时间源及其状态,tracking显示当前同步状态,sourcestats展示统计信息。当无法同步时,通常会出现reach为0、lastrx为零、或者状态为^*之外的符号。例如^?表示从未成功联系过该服务器,^x表示源被排除。

chronyc sources -v
chronyc tracking
chronyc sourcestats

结合journalctl查看chronyd日志,能快速发现具体报错。RHEL中服务日志通常由systemd收集,也可以通过/var/log/messages查看历史记录。常见报错包括No suitable source for synchronization、Temporary failure in name resolution、Request timed out。名称解析失败说明server配置了域名但DNS不通,需要检查/etc/resolv.conf。Request timed out则要回到网络与防火墙层面。No suitable source通常意味着没有任何源被视为可用,可能是时间偏差过大导致chrony拒绝步进。

journalctl -u chronyd -n 50 --no-pager
grep chronyd /var/log/messages | tail -50

如果时间偏差过大,chronyd默认不会直接步进,而是缓慢调整。可以执行chronyc makestep立即调整,或修改配置文件中的makestep参数。例如在/etc/chrony.conf中添加如下内容,表示当超过1秒偏差时,前三次更新允许步进。修改后重启chronyd使配置生效。

makestep 1.0 3

四、手动同步与离线环境应对

如果网络确实无法连接到任何NTP服务器,或者只是临时需要校准时间,可以使用chronyd -q命令实现一次性手动同步。这个命令会让chronyd在前台运行并立即同步后退出,适合脚本或故障恢复场景。执行时需要指定上游服务器地址,可以覆盖配置文件中的默认源。

chronyd -q 'server 192.168.1.10 iburst'

对于完全离线环境,可以在内网搭建一台NTP服务器,或者使用chrony的local stratum功能让本机作为时间源。但需要注意,local stratum只能保证集群内部时间一致,无法与绝对标准时间对齐。如果集群内有节点需要对外提供准确时间,仍建议部署一台能够访问外部NTP的服务器作为统一时间源。

还可以通过ntpd替代方案,不过RHEL已经默认使用chrony,迁移成本较高。建议还是从chrony自身排查,重点检查配置是否正确、端口是否放行、时间偏差是否过大。完成修复后,再次使用chronyc tracking确认System time偏移量逐渐收敛到毫秒级,此时说明时间同步已经恢复正常。

chronyNTP同步RHEL修改时间:2026-08-29 23:57:38

免责声明:​ 已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰,观点力求客观中立。本站旨在免费分享,内容仅供个人学习、研究或参考使用。若引用了第三方作品,版权归原作者所有。如内容涉及您的权益,请联系我们处理。
内容垂直聚焦
专注技术核心技术栏目,确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计,为用户提供无干扰的纯技术知识沉淀,精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进,构建清晰学习路径,帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈,深入技术细节与实践难点。无论是数据库优化还是服务器配置,均结合真实场景与代码示例进行剖析,致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程,从数据库操作到服务器运维,形成完整闭环,一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性,步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目,显著缩短从学习到实践的距离,快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代,紧跟主流技术发展趋势,为用户提供经久不衰的学习价值。