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)"
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
查 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"
