Linux 定时任务错过执行时间怎么在开机后补跑

如果 Linux 关机时正好错过了按日历安排的 systemd 定时任务，最直接的做法是在对应的 .timer 中加入 Persistent=true。它会把定时器上一次触发时间保存到磁盘；机器再次启动并激活定时器时，只要停机期间至少错过过一次日历触发，就会立即激活关联服务一次。这个机制只对 OnCalendar= 生效，而且不是把多天漏掉的每一轮全部补齐。

把任务做成可重复执行的 oneshot 服务，再用 OnCalendar= 配合 Persistent=true。开机后用 journalctl -u 服务名 看实际启动记录，才能确认补跑是否成功。

Persistent=true 为什么能补跑错过的日历任务

OnCalendar= 使用墙上时钟表达式，例如每天凌晨 3:15。若主机在这个时刻关机，普通 timer 只会等待下一次日历匹配；加上 Persistent=true 后，systemd 会保存服务最后一次被该 timer 触发的时间。重新激活 timer 时，如果发现停机期间本来至少应触发过一次，就把服务立即启动一次。

这个选项有两个容易被忽略的边界：它只对日历定时器有效；它表达的是“有遗漏就补一次”，而不是补齐每个漏掉的日期。因此备份、报表、同步这类任务通常要设计成按当前状态补偿，而不是假设 systemd 会提供一条历史执行队列。

先把实际任务放进可重复执行的服务

下面用一个备份脚本做例子。服务采用 Type=oneshot，一次执行结束就退出；脚本本身应使用临时文件、校验或锁避免重复运行造成半成品覆盖。

# /etc/systemd/system/backup.service
[Unit]
Description=Daily application backup

[Service]
Type=oneshot
# 使用绝对路径，避免 timer 环境缺少交互式 Shell 的 PATH
ExecStart=/usr/local/sbin/app-backup.sh

脚本中的退出码也很重要：命令返回非零时，journal 会记录服务失败。不要用一个永不退出的常驻服务承载这种任务，否则下一次触发和补跑之间的状态会变得难以判断。

用 OnCalendar 和 Persistent=true 定义补跑规则

创建同名的 timer 后，systemd 默认会激活同名的 backup.service。WantedBy=timers.target 让它可以随系统的定时器目标启用。

# /etc/systemd/system/backup.timer
[Unit]
Description=Daily application backup timer

[Timer]
# 每天 03:15 触发；可按实际业务改成 weekly 等日历表达式
OnCalendar=*-*-* 03:15:00
# 关机错过日历触发后，重新激活 timer 时补跑一次
Persistent=true
# 让查看输出更容易理解；不改变补跑语义
AccuracySec=1min

[Install]
WantedBy=timers.target

AccuracySec 允许触发时间落在一个精度窗口内，不要把它误当成补跑开关。需要避免多台机器同时打满上游服务时，可以另行评估随机延迟；那是调度分散问题，不是历史遗漏问题。

启用后怎么确认补跑真的发生

文件保存后先重载 unit，再启用 timer。下面的命令只负责让配置进入 systemd 并查看状态：

# 让 systemd 重新读取新增或修改的 unit 文件
sudo systemctl daemon-reload
# 设置开机自动启用，并立刻启动这个 timer
sudo systemctl enable --now backup.timer
# 查看下一次和上一次触发时间
systemctl list-timers --all backup.timer
# 确认最终解析到的关键字段
systemctl cat backup.timer

判断“补跑”不要只看 timer 变成 active。重点是服务日志中的启动时间、结果和脚本自己的业务日志：

# 查看本次启动以来的服务日志，失败时连同错误一起看
sudo journalctl -u backup.service -b --no-pager
# 查看最近一次服务状态和退出码
systemctl status backup.service --no-pager

如果日志显示服务在开机后立刻启动，且退出码为 0，通常说明持久化日历任务完成了补跑；若 timer 有下一次时间但服务失败，应先修复脚本或权限，再决定是否手动 systemctl start backup.service。手动启动不会伪造 timer 的历史触发记录。

常见问题

Persistent=true 会补齐关机期间每一天的任务吗？

不会。它在重新激活时判断是否存在遗漏，并最多触发一次关联服务；需要逐日结算时，应让程序根据业务日期自行补账。

为什么写了 Persistent=true 仍然没有补跑？

先确认 timer 使用的是 OnCalendar=，而不是 OnBootSec=；再确认 timer 确实被重新激活、状态文件可写，以及服务没有因权限、路径或退出码失败。

可以用 systemctl start backup.timer 代替 enable --now 吗？

可以临时启动，但不会设置下次开机自动激活。需要长期运行时使用 enable --now，并用 list-timers 与服务日志分别确认调度和执行。

参考：systemd.timer 官方手册、systemd.service 官方手册。