用 systemd timer 替代 cron：可观测、可依赖、可延迟

很多人默认用 cron 做定时任务。在现代 Linux（尤其是 Ubuntu 24.04）上，systemd timer 往往更合适：失败有日志、可声明依赖、错过窗口还能补跑，排障也更直观。

为什么考虑 timer

cron 的痛点常见有三类：

1. 静默失败：脚本挂了，邮箱没配好就什么都看不到。
2. 环境不一致：PATH、工作目录、环境变量和手动跑不一样。
3. 错过就丢：机器关机或服务未启动时，该点的任务直接跳过。

systemd 把「做什么」和「何时做」拆开：.service 描述动作，.timer 描述时间。journalctl -u your.service 能直接看到每次执行的 stdout/stderr 和退出码。

最小可运行示例

假设要每天 6:00（本机时区）跑一次备份脚本 /usr/local/bin/backup.sh。

/etc/systemd/system/backup.service：

[Unit]
Description=Daily backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup.sh
Nice=10

/etc/systemd/system/backup.timer：

[Unit]
Description=Run backup daily at 06:00

[Timer]
OnCalendar=*-*-* 06:00:00
Persistent=true
RandomizedDelaySec=5m

[Install]
WantedBy=timers.target

然后：

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer
journalctl -u backup.service -n 50 --no-pager

要点：

• Persistent=true：宕机错过窗口后，开机可补跑一次（不是把所有错过的都补上）。
• RandomizedDelaySec：多台机器别卡在同一秒，减轻共享存储或上游压力。
• Type=oneshot：适合跑完就结束的脚本；长驻进程用 simple/notify。

日历表达式速查

不确定解析结果时：

systemd-analyze calendar 'Mon..Fri 09:00:00'

和 cron 怎么选

• 继续用 cron：极简单的一行命令、用户级 crontab、临时一次性提醒。
• 改用 timer：要可靠日志、依赖网络/挂载、补跑、限流（CPUQuota/MemoryMax）、或和其它 unit 联动。

把定时逻辑迁到 systemd 后，运维习惯会变成：改 service/timer → daemon-reload → restart timer → 用 list-timers 和 journalctl 验收。比翻 /var/log/syslog 里 cron 的一行摘要省心得多。

若你还在用「脚本里自己 sleep 循环」冒充定时，优先换成 timer；进程崩溃或重启后，systemd 会按 unit 定义重新拉起调度，而不是靠你手动再起一个后台循环。