别再只用 cron：systemd timer 的五个实用写法

定时任务一多，cron 的短板就藏不住了：机器关机期间错过的任务不会补跑，任务失败了不会自动重试，输出散落在各处、出了问题只能翻邮件或自己加日志重定向。systemd timer 不是要取代 cron，而是给“需要更可靠一点”的定时任务多一种选择：它由两个文件组成，一个 .service 写“做什么”，一个 .timer 写“何时做”，职责分得干净。

最基本的写法是日历触发。service 文件里写好要跑的命令，timer 文件里写 `OnCalendar=daily` 或 `OnCalendar=*-*-* 03:30:00`，再用 `systemctl enable --now xxx.timer` 启用。比 cron 直观的一点是，`systemctl list-timers` 能直接看到每个定时器的下次触发时间、上次触发时间和结果，不用再猜“它到底跑没跑”。

第二个实用写法是开机后延迟跑。有些任务不适合固定在某个钟点，比如清理缓存、拉取配置，机器一开机就跑反而会和启动过程抢资源。用 `OnBootSec=10min`，表示开机 10 分钟后再跑，错峰又省心。配合 `OnUnitActiveSec=1h`，还能做到“上次跑完 1 小时后再跑一次”，适合轮询类任务，比固定钟点更贴合“间隔”这个语义。

第三个是错过补跑，这是 timer 相对 cron 最大的优势。机器在预定时间关机或休眠，cron 的任务就直接丢了；timer 加上 `Persistent=true`，下次开机后会把错过的那次补跑一次。备份、同步这类“宁可晚到、不能不到”的任务，用 Persistent 才安心。但要注意，补跑只补一次，不会把关机期间错过的所有次数全部补齐，这正是它克制的地方。

第四个是失败重试与超时保护。service 文件里可以写 `Restart=on-failure` 和 `RestartSec=30s`，任务失败后 30 秒自动重试；再配 `TimeoutStartSec=5min`，防止某个任务卡住拖垮后续调度。cron 里要实现同样的效果，得自己在脚本里写重试循环和 timeout，散落在每个脚本里既难统一也难排查。

第五个是日志与隔离。timer 触发的 service 默认走 journald，`journalctl -u xxx.service` 就能按服务名查到每次运行的输出，不用再给每个任务单独配日志文件。需要更干净的环境时，还可以在 service 里加 `PrivateTmp=true` 或 `ProtectSystem=strict`，让任务跑在受限的沙箱里，误删或写错路径时破坏面更小。

当然，timer 也有不适合的场景：只是临时跑一次的任务，`systemd-run --on-calendar` 或 `at` 更轻；跨多台机器的调度，还是要交给专门的调度系统；已经稳定运行多年的 cron 任务，也没必要为了换而换。一个简单的判断标准是：任务丢一次无所谓、失败了人工能发现，就继续用 cron；任务不能丢、失败要自动重试、出问题要能快速定位，就值得换成 timer。

一句话总结：cron 胜在简单，timer 胜在可靠。把“不能丢、要重试、要留痕”的那几个关键任务迁到 timer 上，其他的继续留在 cron 里，定时任务这块就既省心又不折腾。