chrony 服务默认安装但未必启用，需用 systemctl status chronyd 检查；若未运行，执行 sudo systemctl enable --now chronyd 启动，并用 ss -tuln | grep :123 确认 udp 123 端口监听。
chrony 服务是否已启用并运行
多数现代 Linux 发行版（如 RHEL 8+、CentOS 8+、Ubuntu 20.04+）默认安装 chrony，但未必开机自启。直接检查状态比猜更可靠：systemctl status chronyd。若显示 inactive (dead) 或 not found，说明服务未就绪。
常见误操作是只运行 chronyc tracking 却忽略后台服务状态——这个命令只查客户端连接，不反映服务端是否在监听或校时。
- 启用并启动：
sudo systemctl enable --now chronyd - 确认监听：
sudo ss -tuln | grep :123（应看到 UDP 123 端口绑定到127.0.0.1或0.0.0.0） - 若提示
Failed to start chronyd.service: Unit chronyd.service not found，可能是包名不同（如 Debian/Ubuntu 用chrony服务名，需改用systemctl status chrony）
/etc/chrony.conf 中最关键的三行配置
chrony 的行为高度依赖 /etc/chrony.conf，但多数人只改 pool 行，漏掉两个关键控制项，导致本地时钟“看似同步”实则漂移。
-
makestep 1.0 -1：允许 chrony 在系统启动时，若时钟偏差超过 1 秒，直接跳变而非缓慢调整。没有这行，虚拟机恢复快照或宿主机休眠后，时间可能卡住数分钟 -
rtcsync：将系统时间定期写入硬件时钟（RTC），避免重启后时间回退。不加此行，hwclock --show和date可能长期不一致 -
pool pool.ntp.org iburst：使用iburst而非burst，前者在初始同步时发 4 个包加速收敛，后者仅用于已同步后的保活
改完记得重载：sudo systemctl reload chronyd，不是 restart——reload 才会重新读取配置并保持已有会话。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
验证同步是否真正生效，而不是“连上了就行”
chronyc tracking 显示 Leap status : Normal 并不等于时间已稳。真正要看的是偏移量（Offset）和估计误差（Estimated error）是否持续收敛。
- 运行
chronyc sources -v：关注每行末尾的^*标记——只有带星号的源才被实际用于校时；若全是^-或^+，说明 chrony 认为所有源不可靠（常见于防火墙阻断 NTP、DNS 解析失败、或池域名返回了私有 IP） - 连续执行
chronyc tracking3 次，观察Offset是否从 ±50ms 逐步收窄到 ±5ms 内；若始终在 ±100ms 波动，大概率是网络延迟高或源服务器响应差，可换国内源如pool ntp.aliyun.com iburst - 注意
System clock wrong by这一行：它反映 chrony 当前认为系统时间与参考源的差距，单位是秒。首次启动后该值可能很大，但 2–3 分钟内应快速趋近于 0
遇到 chronyd 启动失败或拒绝同步的典型报错
最常见的两个错误都和权限与冲突有关，和 NTP 时代的老经验不兼容。
-
Could not open /dev/adjtimex: Permission denied：发生在容器或某些最小化系统中，内核未启用CONFIG_ADJTIMEX或用户无权访问。解决方法是确保运行在 privileged 容器，或在宿主机上添加cap_sys_time+ep权限给 chronyd -
Source 192.168.1.10 is rejected because it is not in the same subnet：这是 chrony 默认开启的“孤立检测”（orphan mode）触发的。当所有外部源失效，chrony 会拒绝接受局域网内其他 chrony 实例的时间（防环路）。若你确实在内网部署了主 chrony 服务器，需在客户端配置中显式加offline 192.168.1.10或在服务端关掉orphan检测 - 若
chronyc sources返回空，且journalctl -u chronyd -n 20显示DNS resolution failed for pool.ntp.org，说明 chrony 启动早于网络就绪。加After=network-online.target到/usr/lib/systemd/system/chronyd.service的[Unit]段，并sudo systemctl daemon-reload
本地时钟同步最脆弱的环节不在配置本身，而在“以为配好了就一劳永逸”——chrony 的健康依赖持续的网络可达性、稳定的硬件时钟晶振、以及没有其他进程（如 systemd-timesyncd、ntpd）偷偷抢占 123 端口。每次系统升级或内核更新后，建议手动跑一次 chronyc tracking && chronyc sources 快速过一遍。
