systemd 不支持 OnCalendar 中使用非整数间隔（如“每2.5小时”），00/2:30 是错误写法；正确方案是选用 OnUnitActiveSec=2h30min 实现连续偏移触发，或手动枚举 OnCalendar 时间点以实现每日重置周期。
systemd 不支持 `oncalendar` 中使用非整数间隔（如“每2.5小时”）；`00/2:30` 是错误写法；正确方案是选用 `onunitactivesec=2h30min` 实现连续偏移触发，或手动枚举 `oncalendar` 时间点以实现每日重置周期。
在 systemd 中实现「每 2.5 小时运行一次」的任务看似简单，但因日历时间的离散性与周期性限制，OnCalendar 并不支持小数小时粒度的重复逻辑。你遇到的问题——OnCalendar=00/2:30 被解析为「小时字段每 2 小时（00、02、04…）且分钟固定为 30」，即实际匹配 *:00:30 和 *:02:30 等组合，最终退化为每 2 小时触发一次（如 00:30、02:30、04:30…），而非期望的 00:00 → 02:30 → 05:00 → 07:30 → 10:00… 序列。
根本原因在于：systemd 的 / 操作符仅作用于单个时间字段（如 hour/2 或 minute/30），不能跨字段表达复合周期（如 “2 小时 30 分钟”）。此外，2.5 小时 × n 次无法整除 24 小时（24 ÷ 2.5 = 9.6），因此该序列天然不具备全天周期性——若强制按日对齐（如每天从 00:00 开始），必须显式定义每天内所有有效时间点。
✅ 推荐方案：使用 OnUnitActiveSec（适用于连续偏移场景）
若你希望服务严格按「上次执行后 2 小时 30 分钟」再次触发（例如：00:00 → 02:30 → 05:00 → 07:30 → 10:00 → … → 25:00 即次日 01:00），应弃用 OnCalendar，改用基于启动间隔的定时器：
[Unit] Description=Run every 2.5 hours (offset-based) [Timer] OnActiveSec=0s # 首次立即触发（可选） OnUnitActiveSec=2h30min # 此后每次在上一次激活后 2h30m 触发 Persistent=true # 若错过触发时间（如系统关机），唤醒后补执行 [Install] WantedBy=timers.target
⚠️ 注意事项：
-
OnUnitActiveSec依赖前一次服务成功启动（而非完成），若服务长时间阻塞或崩溃，可能影响后续调度节奏； - 可配合
AccuracySec=1s（默认 60s）提升精度，避免批量唤醒抖动； - 如需随机延迟防雪崩，添加
RandomizedDelaySec=30s； - 此方式不依赖系统时钟对齐，适合后台轮询、数据同步等对绝对时间不敏感的场景。
✅ 备选方案：显式枚举 OnCalendar（适用于每日重置场景）
若业务要求严格按「每天 00:00 重启计时」，即序列在每日边界截断并重新开始（00:00, 02:30, 05:00, 07:30, 10:00, 12:30, 15:00, 17:30, 20:00, 22:30），则需手动列出全部 10 个时间点（24h / 2.5h = 9.6 → 向下取整为 9 个完整周期 + 起始点 = 10 个）：
[Unit] Description=Run every 2.5 hours (daily-aligned) [Timer] OnCalendar=00,05,10,15,20:00 OnCalendar=02,07,12,17,22:30 Persistent=true [Install] WantedBy=timers.target
? 提示：使用 systemd-analyze calendar --iterations=12 "00,05,10,15,20:00" "02,07,12,17,22:30" 验证生成的时间序列是否符合预期。
? 总结：
- ❌
00/2:30是无效语法，systemd 会静默降级解析，导致行为偏差； - ✅ 追求「连续偏移」→ 用
OnUnitActiveSec=2h30min； - ✅ 追求「每日对齐」→ 显式枚举
OnCalendar多行； - ? 所有修改后务必执行
sudo systemctl daemon-reload && sudo systemctl restart your-timer.timer，并用systemctl list-timers --all实时验证下次触发时间。
