systemd timer 延迟几分钟甚至几小时的 OnCalendar 精度优化

systemd timer 的 OnCalendar 默认精度为1分钟，实际触发时间可能偏差达60秒；需通过AccuracySec参数调低至秒级或毫秒级以提升精度，但会增加CPU唤醒频率。

systemd timer 的 OnCalendar 默认精度是 1 分钟

systemd 在默认配置下会对 OnCalendar 触发时间做“对齐”处理，把所有计划在同分钟内的事件批量调度，最大允许误差达 60 秒。这不是 bug，而是设计选择：降低唤醒频率、减少系统抖动。但如果你写的是 OnCalendar=*-*-* *:*:30（每分钟第 30 秒触发），实际可能在 xx:xx:30–xx:xx:59 任意时刻运行——这对监控轮询、定时快照等场景已属不可接受。

修改 AccuracySec 可提升到毫秒级（但需谨慎）

AccuracySec 是 timer unit 中控制精度的核心参数，默认值为 1min。把它设为 1s 或 100ms 确实能缩小偏差，但要注意：

• 值越小，systemd 越频繁地唤醒并检查时钟，尤其在低功耗设备或虚拟机中会增加 CPU 唤醒次数
• 低于 1s 时，systemd 不再保证严格准时（底层依赖 clock_gettime(CLOCK_MONOTONIC) 和内核定时器精度），实测 AccuracySec=100ms 在多数桌面环境可稳定控制在 ±200ms 内
• 必须写在 timer unit 文件的 [Timer] 小节里，且不能和 RandomizedDelaySec 同时启用（后者会覆盖前者效果）

示例：

[Timer] OnCalendar=*-*-* *:*:00 AccuracySec=1s Persistent=true

OnCalendar 时间表达式本身不决定精度，只定义匹配规则

很多人误以为写 OnCalendar=*-*-* *:*:00.500（带毫秒）就能触发半秒级任务，但 systemd 解析器根本不支持小数秒语法，该行会被静默忽略或报错 Invalid argument。真正起作用的是：

• OnCalendar 仅用于生成下一个匹配时间点（按日历逻辑计算）
• 最终是否在这个时间点执行，完全由 AccuracySec + 当前系统负载 + 定时器队列状态共同决定
• 如果需要亚秒级重复调度（如每 500ms 采样一次），OnCalendar 不适用，应改用 OnUnitActiveSec 或外部工具（如 sleep 循环 + systemd-run --scope）

RealtimeClock=yes 并不能解决精度问题

有些文档建议启用 RealtimeClock=yes 来“使用硬件时钟”，但它只影响 timer 启动时的初始对齐行为（比如开机后第一次触发是否等待到整点），和后续每次触发的精度无关。它甚至可能引入 NTP 调整导致的跳变——例如 NTP 向后校正 1 秒，timer 可能直接跳过一次触发。除非你明确需要跨系统重启保持日历语义对齐（比如每日凌晨 2 点备份），否则不必开启。

真正影响长期稳定性的反而是 Persistent=true：它让 timer 在错过触发时间后（如机器休眠）补跑一次，但这会进一步放大延迟感知——你以为延迟了 2 小时，其实是 timer 在唤醒后立刻“补偿执行”，而非准时执行。