Linux怎么查看同步失败重试日志

systemd-timesyncd、chrony、ntpd 同步失败日志不单独生成，而是混在系统日志中：timesyncd 日志仅存于 journal，需用 journalctl -u systemd-timesyncd 过滤；chrony 默认写入 /var/log/chrony/chrony.log（需配置 logdir）或 journal；ntpd 日志通常在 /var/log/messages 或 syslog 中。

一旦 systemd 服务的同步出了问题，比如 systemd-timesyncd 校时失败，或者 chrony、ntpd 出现同步异常，系统并不会额外生成一份“同步失败重试日志”文件。重试过程、超时记录、服务器不可达这类信息，通常都会散落在系统日志或服务自己的日志里。所以，直接去搜“同步失败重试”往往是找不到结果的，关键不在关键词本身，而在于先搞清楚日志写到了哪里、再按正确方式过滤。

查 systemd-timesyncd 同步失败和重试记录

systemd-timesyncd 是 systemd 自带的轻量时间同步服务，失败重试行为只记在 journal 中，不落盘到 /var/log/ 下的文本日志。

一个很常见的情况是：执行 timedatectl status 时会看到 System clock synchronized: no，可再去看 systemctl status systemd-timesyncd，往往还是抓不住问题到底出在哪。
真正的重试日志其实藏在 journal 里，而且默认日志级别是 info，所以需要手动筛出来：
• 执行 journalctl -u systemd-timesyncd -p info | grep -i "retry|timeout|no response|failed"
• 如果想看最近 5 分钟内所有同步动作，包括成功、失败和重试，可以用 journalctl -u systemd-timesyncd --since "5 min ago"
• 还要注意一点：这个服务的重试间隔由 /etc/systemd/timesyncd.conf 里的 PollIntervalMinSec= 和 PollIntervalMaxSec= 控制，默认会从 16s 到 32min 进行指数退避。也就是说，失败之后下一次重试可能会隔很久才发生，所以排查时别只盯着“刚刚那几分钟”的日志

查 chrony 的同步失败与重试细节

chrony 日志更详细，但默认不输出重试过程，需主动启用调试或检查其状态输出。

• 先确认服务是否运行：systemctl is-active chronyd
• 查当前同步状态：chronyc tracking（看 Leap status、System clock 是否偏移过大）和 chronyc sources -v（看每个 NTP 源的 ^*、^+、^- 状态，? 表示无法访问，~ 表示抖动过大）
• 日志默认写入 /var/log/chrony/chrony.log，但需在 /etc/chrony.conf 中配置 logdir /var/log/chrony 并重启服务；否则只进 journal
• 若已启用日志目录，用 tail -f /var/log/chrony/chrony.log | grep -i "source.*unreachable|sync.*fail|timeout"
• journal 中可查重试行为：journalctl -u chronyd -p info | grep -E "(Source|Sync|Retry|Timeout)"

查 ntpd 同步失败和重试（已逐步淘汰，但仍存在）

ntpd 不主动记录“重试”，但会通过 syslog 输出连接失败和时钟调整警告。

• 默认日志路径是 /var/log/messages 或 /var/log/syslog，取决于发行版
• 执行 grep -i "ntp.*timeout|no server suitable|step time|clock not synchronized" /var/log/messages
• 若启用了 -d 调试模式（不推荐生产环境），日志会更细，但通常只进 stdout/stderr，需靠 journalctl -u ntp 捕获
• 注意：ntpd 在检测到大偏移时会“step”而非“slew”，这本身不是失败，但可能被误读为同步异常——要看 ntpq -p 输出中各源的 st（stratum）和 reach（八进制可达性，377 表示全通，0 表示完全不可达）

为什么看不到“重试 X 次后放弃”这类明确日志？

绝大多数时间同步服务的设计哲学是“持续尝试”，不设固定重试上限，也不会在日志里计数写“第3次重试失败”。它们只记录每次尝试的结果（成功/超时/拒绝/无响应），你得靠时间戳+关键词自己串起来看是否密集失败。
• systemd-timesyncd 重试间隔指数增长，两次失败日志可能相隔数分钟甚至小时
• chrony 对每个源独立维护状态，一个源挂了不影响其他，日志里看到的是单源反复失败，不是全局重试计数
• 真正需要“重试次数”统计？得自己用 awk 或 grep -c 统计单位时间内的失败行数，例如：journalctl -u chronyd --since "1 hour ago" | grep -c "Source .* unreachable"