systemd timer Persistent=true 深度解析：时间戳机制与补跑逻辑

用 systemd timer 管理计划任务的人，迟早都会碰到一个叫Persistent=true的选项。早晚而已。

最常见的剧本是这样的：你写了一个每天凌晨 2 点跑的备份 timer，头天晚上合盖关机，第二天上午开机一看，备份没跑。于是你开始翻文档，搜到“加上 Persistent=true 就行”。加完之后发现，开机那一刻备份任务确实补跑了。可你要是追一句“为什么会补跑”“到底补几次”“是不是所有 timer 都适用”，很多人就答不上来了。

这很危险。因为Persistent=true不是“让定时任务更持久”，也不完全是“开机后补偿执行”，它背后有一套基于时间戳的判定逻辑，用对了是救火工具，用错了可能让任务在你不想跑的时候突然跑一遍。这篇文章我就把 systemd timer 里这个参数的真实语义、底层机制、适用边界和验证方法完整讲一遍，下次配置计划任务时能少走点弯路。

1. 先从“为什么我一开机任务就跑了”说起：Persistent 的真实语义

1.1 文档里的原话到底在说什么

systemd 官方手册对Persistent=的说明不算长，但挺绕。我拆开说：

Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive.

翻译成人话：Persistent=true会把“服务上次被触发的时间”持久化到磁盘。等到 timer 单元被激活时，systemd 会做一个检查——如果在这个 timer 处于非活跃状态的这段时间里，按照计划本该触发至少一次，那现在就立刻触发一次。

注意这里的关键词不是“开机”，而是“timer 被激活”。开机只是最常见的激活场景，因为只要你把 timer 设置了开机自启，系统一启动，timer 就会被激活。但反过来说，手动systemctl start一个 timer 同样也是一次激活，也会触发这个检查。这一点很多人没意识到，后面我会专门讲怎么利用它做实验。

1.2 最容易踩的三个认知误区

我见过太多人对Persistent=true产生误解，归纳下来主要是这三种：

误区一：以为它能保证任务“常驻运行”。这是被“持久”两个字带偏了。Persistent和进程常驻、守护进程、服务不退出这些事情没有半点关系。它只是一个开关，决定 systemd 要不要把“上次触发时间”写到磁盘，并在激活时基于这个时间做补跑判断。timer 本身的启停逻辑是另一回事。

误区二：以为它是“开机必补跑”。不是所有任务开机都会补跑。补跑的条件是“在 timer 不活跃的这段时间里，至少错过了一个原定的触发点”。如果你是中午 12 点开机，而任务原本是晚上 11 点跑，那开机时不会触发，因为没有错过任何计划点。

误区三：以为错过几次就补几次。这是最要命的一个。Persistent=true在多个计划点错过的场景下，只在重新激活时补跑一次，不是把错过的每个周期都补一遍。为什么这么设计，我在第 3 节会从时间戳机制的角度讲清楚。

1.3 它和 cron、anacron 的关系

用过一个类比你就懂：cron 是“闹钟到点就响，你睡过头它也不会补叫”；anacron 是“你睡过头醒来之后，发现闹钟响过，它会催你现在赶紧去做”；而 systemd 的Persistent=true更像一个精简版 anacron——它只补一次，不会把错过的历史周期逐个补齐。

这个特性对笔记本、台式机、虚拟机这类经常关机休眠的环境特别有价值。它解决的核心问题是：机器没开机的时候，计划任务不执行是正常的，但开机之后不应该直接跳过，而应该有机会补上最近一次。

2. 两类计时器：OnCalendar 和单调计时器，谁才能吃 Persistent

2.1 OnCalendar 绝对时间触发

systemd timer 里最像 cron 的写法就是OnCalendar=。它用一套类日历表达式描述绝对时间，例如：

OnCalendar=*-*-* 02:00:00 OnCalendar=Mon..Fri 10:00:00 OnCalendar=Sat,Sun 03:30:00 OnCalendar=*-*-1,15 04:00:00

这些表达式都对应墙上时钟的具体时刻。你可以用systemd-analyze calendar查看某个表达式的实际换算结果：

systemd-analyze calendar "*-*-* 02:00:00"

输出会列出下一次触发时间、上次触发时间，以及 UTC 时间。这个命令在调试OnCalendar表达式时非常有用，建议养成习惯。

2.2 单调计时器：从某个事件点开始计时

另一类 timer 用的不是墙上时间，而是“相对某个事件已经过去了多久”。包括：

• OnBootSec=：从系统启动开始算
• OnActiveSec=：从 timer 单元被激活开始算
• OnUnitActiveSec=：从关联的 service 上次被激活开始算
• OnUnitInactiveSec=：从关联的 service 上次停止开始算

这些适合做固定间隔任务，比如“每 12 小时检查一次证书”“每 5 分钟同步一次数据”。它们不关心现在是几点，只关心距离上一个事件点过了多久。

2.3 Persistent 只对 OnCalendar 生效

这是很多人配置时最容易忽略的前提：Persistent=true只有配合OnCalendar=才有意义。

原因在于“错过”这个概念只在绝对时间下才成立。你关机期间，墙上时钟照样往前走，所以凌晨 2 点这个触发点会“错过”。但单调计时器是以开机、激活等事件为基准重新计时的，机器关机时它的计时基准根本不存在，谈不上“错过”或者“补跑”。

模块化对比一下：

如果你在一个只配置了OnBootSec=1h的 timer 上写Persistent=true，systemd 不会报错，但不会产生任何实际效果。属于“写了白写，但也不影响运行”。

2.4 另一个隐蔽前提：timer 必须开机自启

Persistent=true生效还有个前置条件：timer 本身得被 enable，开机后能被激活才行。如果你只是systemctl start xxx.timer而没有enable，那重启后 timer 不会自动激活，时间戳检查自然也不会在开机时发生。

所以正确用法是：

sudo systemctl enable --now xxx.timer

如果你在写自定义 timer，还需要在[Install]段里声明WantedBy=timers.target，否则enable都不知道把自己挂到哪里去。这一步漏了，一切白搭。

3. 底层机制拆解：时间戳文件与补跑判定流程

3.1 时间戳到底存在哪

设置Persistent=true后，systemd 会把上次触发时间写到一个磁盘文件里。路径通常在：

/var/lib/systemd/timers/

文件名是stamp-加上 timer 单元名，比如我的备份 timer 叫daily-backup.timer，那对应文件就是：

/var/lib/systemd/timers/stamp-daily-backup.timer

文件内容非常简单，基本就是一个 Unix 时间戳，表示“这个 timer 关联的 service 上次是什么时候被触发的”。你可以用stat直接看修改时间，或者用下面的命令读取内容：

sudo cat /var/lib/systemd/timers/stamp-daily-backup.timer

不同 systemd 版本和发行版可能在具体实现上有细微差别，但总体思路都是“把 last-trigger 时间落盘”。

3.2 一次完整的补跑判定流程

假设我配置了一个每天凌晨 2 点执行的任务：

OnCalendar=*-*-* 02:00:00 Persistent=true

正常启动后的判定流程是这样的：

第一，系统开机，timers.target 开始拉起所有 enable 状态的 timer，daily-backup.timer被激活。第二，systemd 读取/var/lib/systemd/timers/stamp-daily-backup.timer，拿到上一次触发时间。第三，根据OnCalendar表达式，计算从上一次触发时间到现在，是否已经跨过了至少一个凌晨 2 点。第四，如果跨过了，就立即触发一次关联的 service。第五，触发完成后，把当前时间写回 stamp 文件。

这套流程和“关机”没有必然绑定。你甚至可以手动触发：把 timer stop 掉，等过了计划触发点再 start，同样会看到一次补跑。因为它只看 timer 处于 inactive 的这段时间里有没有错过触发点。

3.3 为什么“只补一次”而不是“每次都补”

很多人纠结的点在于：如果关机了三天，是不是应该把三天的任务都补上？

不会。Persistent=true的设计哲学是“补最近一次，让你尽快回到正轨”，而不是“历史欠账一次性结清”。原因有两层。

第一，从机制上讲，只要触发了一次，systemd 就会把 stamp 文件更新为当前时间。更新之后，原来的错过时间点就不存在了，剩下的都是未来的触发点。判定依据变了，自然不会再补。

第二，从实用角度讲，逐个补跑往往是坏事。假设你有一个每小时采集一次温度数据的任务，周六关机 8 小时，开机后它补跑一次，还能接受；如果它把错过的 8 次全都补跑一遍，不仅毫无价值，还会瞬间产生一堆请求，把下游系统打爆。

所以这个“只补一次”的设计不是偷懒，而是深思熟虑的结果。如果你真的需要把错过的多次数据都补上，应该由你的业务脚本去处理，比如脚本启动时检查时间范围，自行决定要补哪些数据，而不是依赖 timer 本身。

3.4 Persistent 与 AccuracySec、RandomizedDelaySec 的关系

这里顺带提两个容易产生连锁反应的配置项。

AccuracySec=控制 timer 触发的时间精度，默认是 1 分钟。也就是说，即便写的是02:00:00，实际也可能在 02:00 到 02:01 之间触发。对绝大多数计划任务这个精度足够。RandomizedDelaySec=则会在触发前增加一个随机延迟，主要用于避免大量机器同时触发导致的“惊群”效应。

这两个配置在正常触发时会生效。但在“开机补跑”这个场景下，你最好实际观察一下日志，确认随机延迟是否也加到了补跑触发上。不同 systemd 版本对这个边角场景的处理可能略有差异，生产环境里别想当然，用journalctl看一眼最稳妥。

4. 三份可以直接抄的 Timer 配置和它们的实际表现

4.1 配置 A：每天凌晨备份，关机后开机补跑

这是最典型的Persistent=true用例。写两个文件：

# /etc/systemd/system/daily-backup.service [Unit] Description=Daily backup job [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/daily-backup.timer [Unit] Description=Run daily backup with catch-up [Timer] OnCalendar=*-*-* 02:00:00 Persistent=true RandomizedDelaySec=5min [Install] WantedBy=timers.target

启用：

sudo systemctl daemon-reload sudo systemctl enable --now daily-backup.timer

这个配置的实际表现可以推演一下。第一晚机器正常开着，凌晨 2 点触发备份，stamp 更新。第二晚你合盖关机，第二天早上 9 点开机。timer 激活后发现，从上次 2 点触发到开机这一刻，已经跨过了今天凌晨 2 点这个触发点，于是立即补跑一次备份，再更新 stamp。第二天晚上你又是凌晨 1 点关机，但这次没有错过 2 点触发点，因为还没有到 2 点你就关机了，第二天开机也不会补跑。下次正常触发是在第三天凌晨 2 点。

理解这个节奏很关键：Persistent=true不会“只要关机就补跑”，它只会在“关机的这段时间里确实错过了一个计划点”时才补跑。

4.2 配置 B：每小时数据采集，关机错过多个周期只补最近一次

对一个每小时整点采集数据并写入文件的任务：

# /etc/systemd/system/hourly-collect.service [Unit] Description=Hourly data collection [Service] Type=oneshot ExecStart=/usr/local/bin/collect.sh

# /etc/systemd/system/hourly-collect.timer [Unit] Description=Hourly collection with catch-up [Timer] OnCalendar=hourly Persistent=true [Install] WantedBy=timers.target

如果机器从凌晨 1 点到早上 7 点关机，按整点算，期间错过了 2 点、3 点、4 点、5 点、6 点总共五个触发点。开机后，hourly-collect.timer激活，检测到至少错过了一个触发点，于是立即触发一次hourly-collect.service。然后 stamp 更新，任务回到正轨。下一个正常触发点是 8 点整。

也就是说，五个小时的数据缺口，只有一个补跑机会。如果采集脚本自己不处理历史缺失，那这五个小时的数据就是不完整。设计这类任务时，一定要让脚本具备“启动时检查缺失时间范围”的能力，或者接受数据缺失的现实。这不是Persistent的缺陷，而是它的设计意图。

4.3 配置 C：每周日志清理，到底开不开 Persistent

按需评估的例子也很典型。假设任务是把超过 30 天的日志删掉，每周日凌晨 3 点执行：

# /etc/systemd/system/log-purge.service [Unit] Description=Purge old logs [Service] Type=oneshot ExecStart=/usr/local/bin/log-purge.sh

# /etc/systemd/system/log-purge.timer [Unit] Description=Weekly log purge [Timer] OnCalendar=Sun *-*-* 03:00:00 [Install] WantedBy=timers.target

这种任务我反而建议不要加Persistent=true。原因很简单：日志清理晚几天做没有严重后果，但如果你在一个周末关机，周一开机后它立刻补跑清理任务，正好赶上其他开机自启服务抢磁盘 IO，反而可能拖慢启动阶段的表现。

对于这类“容忍延迟、不希望意外补跑”的任务，保持默认的Persistent=false更合适。错过就错过，下一个周期再清理也行。

4.4 别忘了处理同名 service 的开机自启

这是配置 timer 时一个特别隐蔽的坑：如果对应的 service 之前被你 enable 过，那开机时 service 本身会直接启动，而 timer 又会触发一次，导致双重执行。

正确做法是先停掉并禁用 service 的自动启动，只保留 timer 来驱动：

sudo systemctl disable --now daily-backup.service sudo systemctl enable --now daily-backup.timer

改成这种模式之后，service 只应该被 timer 启动，而不是被multi-user.target直接拉起来。如果之前配过 cron，也要把 cron 里的对应条目停掉，避免两套调度同时跑。

5. 验证、模拟与排坑：教你亲手确认 Persistent 是否生效

5.1 用 list-timers 看触发状态

配置完之后，最快的确认方式是：

systemctl list-timers --all

输出里能看到每个 timer 的下一次触发时间、上次触发时间、对应的 service 等。如果任务刚刚补跑过，LAST一列会显示最近一次的实际触发时间。这个时间应该和你开机时间接近，而不是计划中的凌晨 2 点。

如果想只看某个 timer 的具体状态，可以附加单元名过滤：

systemctl list-timers daily-backup.timer

另外systemctl show daily-backup.timer会输出一堆属性，里面有LastTriggerUSec、NextElapseUSecRealtime、Persistent等字段，适合在脚本里做状态检查。

5.2 journal 日志里如何确认补跑

补跑一旦发生，timer 会立刻启动对应的 service，这个过程一定会在日志里留下痕迹。查看本次开机以来的 timer 日志：

journalctl -u daily-backup.timer -b

再查看 service 本身的日志：

journalctl -u daily-backup.service -b

如果补跑发生在早上 9 点开机后，service 的日志时间戳应该落在 9 点附近。如果你发现 service 日志里有两个相近的执行时间，那就要警惕是不是 service 自身开机启动和 timer 补跑撞在一起了。

5.3 手动模拟“错过触发”的实验方法

不用真关机也能验证Persistent=true的判定逻辑。做一个测试 timer，每分钟触发一次：

# /etc/systemd/system/catchup-test.timer [Unit] Description=Persistent catch-up test [Timer] OnCalendar=*-*-* *:*:00 Persistent=true [Install] WantedBy=timers.target

# /etc/systemd/system/catchup-test.service [Unit] Description=Persistent catch-up test service [Service] Type=oneshot ExecStart=/bin/touch /tmp/catchup-test.log

启用并确认正常运行后，执行：

sudo systemctl stop catchup-test.timer sleep 100 sudo systemctl start catchup-test.timer

如果Persistent=true生效，start 之后会立刻看到/tmp/catchup-test.log被更新，而不是等到下一个整分钟。这个实验说明了一个非常重要的事实：补跑条件只看“timer 是否曾经 inactive”，和是否关机无关。手动重启 timer 本身就足以触发一次补跑。

实验做完记得清理：

sudo systemctl disable --now catchup-test.timer catchup-test.service sudo rm /etc/systemd/system/catchup-test.timer /etc/systemd/system/catchup-test.service sudo systemctl daemon-reload

5.4 五个实战高频坑

第一，配置写错位置。Persistent=true必须写在[Timer]段里，写进[Service]段 systemd 会直接忽略掉，而且通常不报错。用systemd-analyze verify检查一遍最放心。

第二，enable 的是旧文件。你改了/etc/systemd/system/xxx.timer，但没有daemon-reload，systemd 加载的还是内存里的旧配置。每次改完 timer/service 都执行一次：

sudo systemctl daemon-reload

第三，时间戳文件污染。如果stamp-xxx.timer文件被误删或内容异常，下次 timer 激活时 systemd 可能认为长时间未触发，于是触发一次补跑。生产环境中不要乱动/var/lib/systemd/timers/下的文件。

第四，任务执行时间太长导致触发点被跳过。比如任务本身要跑 3 小时，而计划是每小时触发一次。Persistent=true不会在任务还在跑的时候强行补跑下一次，也不会立即补偿，它会等下一次OnCalendar周期再次触发。如果你的任务经常发生重叠，应该把触发策略改成OnUnitActiveSec=或OnUnitInactiveSec=，思路完全不同。

第五，容器和只读文件系统。如果你的/var是只读挂载或容器环境中没有持久化，Persistent的时间戳没法落盘，那这个功能就名存实亡。确定要在容器里跑 timer 之前，先验证/var/lib/systemd/timers/是否可写。

6. 生产环境配置选型的几条经验

6.1 什么场景真的需要 Persistent=true

我的判断标准很简单：任务是否有“最近一次执行”的硬约束，同时机器可能长时间处于关机或休眠状态。

符合这个标准的有：每日备份、每日报表生成、每日数据同步、每日证书检查。这些任务的特点是，今天的数据如果你漏了，明天再跑就不完整了，至少要在开机后尽快补上最近一次。

不符合的有：日志清理、缓存过期、临时文件删除、只做增量入队的低优先级任务。这些任务晚一天甚至晚一周执行，影响都可控，没必要在开机时刻突然插进来。

另外，业务幂等性也是一个重要考量。如果你的任务不是幂等的，比如发邮件通知、账户扣款、单据推送，那Persistent=true带来的“开机补跑”可能引发重复操作。这类任务要么设计好幂等保护，要么干脆别开Persistent。

6.2 避免开机瞬间的惊群效应

当多个 timer 都设置了Persistent=true，并且机器关机超过一段时间，开机那一刻会有一批任务同时补跑。如果这些任务都去访问同一个数据库或者同一台 API 服务，瞬时压力会很大。

缓解办法是给每个 timer 加上RandomizedDelaySec：

[Timer] OnCalendar=*-*-* 02:00:00 Persistent=true RandomizedDelaySec=10min

这样补跑不会集中在同一秒，而是分散在 10 分钟内陆续执行。对于备份、采集、报表这类任务来说，10 分钟的随机延迟完全无感。

6.3 给后来人留好注释

用 systemd timer 最容易被后面接手的人坑到的地方，就是“明明写了凌晨 2 点，为什么一开机就跑了”。建议直接在 timer 文件里写注释说明：

[Unit] Description=Daily backup (Persistent=true will catch up after offline period)

这样无论谁来看，都知道这个“反常”行为是故意配置的，而不是系统抽风。

6.4 监控 timer 状态

生产环境里不要把 timer 配置完就不管了。至少可以加一个简单的检查：

systemctl is-active daily-backup.timer systemctl is-active daily-backup.service

或者监控systemctl list-timers --all里有没有异常消失的条目。timer 的丢失很多时候比 service 崩溃更难发现，因为系统不会主动报警。没有日志采集环境的话，最简单的方式是在备份脚本里带一个“上轮执行时间”检测，超过阈值就输出警告。

我在实际项目里见过不少配置问题，根源都是对Persistent=true的理解停在“开机补跑”四个字上，没有想清楚它背后的时间戳判定逻辑。其实把它拆开看很简单：落盘一个时间，激活时查一次，错过就补一次，然后把时间更新掉。理解到这一层，什么时候该用、什么时候不要用、验证时该看哪里，心里就都有数了。