systemd.timer Unit 怎样指定被激活的服务

配置 systemd.timer 触发指定服务非常简单，默认规则下 timer 会自动调用和自身文件名同名的 .service 单元，你也可以直接在 timer 单元的配置段里显式声明 Unit= 参数，填写你想要关联的任意服务名称即可，不需要让两个单元文件名保持一致。

systemd.timer 优先匹配同名 .service 作为激活目标，也可通过 timer 配置中的 Unit= 字段自定义指定任意待激活的服务单元。

我第一次把一个清理任务改成 systemd timer 时，真正卡住的不是 OnCalendar=，而是 timer 到底会激活哪个 service。答案很明确：如果不写 Unit=，backup.timer 默认激活同名的 backup.service；如果两个 unit 名称不同，就在 [Timer] 中显式写出目标 service。

把 Unit=backup-worker.service 写在 timer 的 [Timer] 段，目标参数必须是要激活的 unit 名称，不能写成另一个 .timer。名称相同的简单场景可以依赖默认规则，名称不同或希望绑定关系一眼可见时再显式配置。

先看 timer 的默认同名绑定

systemd 的默认规则是去掉 timer 文件的后缀，再把剩下的名字当作 service 名称。因此 backup.timer 会寻找 backup.service。这条规则适合一个定时器只对应一个同名任务的场景，少写一个配置项，也不容易把目标写错。

但当项目里已经有一个复用的 worker，或者 timer 名称表达的是调度策略而不是任务名称时，默认规则就不够直观。例如我希望用 nightly-maintenance.timer 调度 maintenance-worker.service，此时如果省略 Unit=，systemd 会按默认规则寻找 nightly-maintenance.service，而不是我想要的 worker。

名称不同就把 Unit= 放进 [Timer]

显式绑定时，Unit= 必须写在 timer 文件的 [Timer] 段。它的值是被激活的 unit 名称，例如下面让 nightly-maintenance.timer 调度 maintenance-worker.service：

# nightly-maintenance.timer：只负责定义触发时间和目标 unit
[Unit]
Description=夜间维护调度器

[Timer]
# 每天 02:30 触发指定的 service，而不是按 timer 名称猜目标
OnCalendar=*-*-* 02:30:00
Unit=maintenance-worker.service

[Install]
# 让它可以被 timers.target 统一拉起
WantedBy=timers.target

对应的 service 独立描述真正要执行的动作：

# maintenance-worker.service：定义被 timer 激活后的工作
[Unit]
Description=夜间维护任务

[Service]
# 一次性任务执行结束后退出，不把维护进程长期留在后台
Type=oneshot
# 使用绝对路径，避免非交互服务缺少预期的 PATH
ExecStart=/usr/local/sbin/maintenance-worker

这里的关键不是把两个文件写在一起，而是两个 unit 之间的名字关系：Unit= 指向 maintenance-worker.service，而 ExecStart= 只属于 service。把 Unit=maintenance-worker.timer 写进去并不能表达“激活另一个定时器”，因为该选项要求目标 unit 的后缀不是 .timer。

重复触发时要留意 service 的 active 状态

我后来遇到的第二个误判是：以为 timer 每次到点都会重新创建一个 service 进程。官方行为是，如果目标 unit 在 timer 到期时已经处于 active，systemd 不会把它重启，也不会为同一个 service 生成新的实例。长时间运行的任务因此要自己考虑是否允许重入。

对 Type=oneshot 来说，RemainAfterExit=yes 会让 service 在主进程退出后仍保持 active。这样重复 timer 到点时，它可能只在第一次被激活；如果希望每次到点都能再次触发，通常不要让一次性任务永久保持 active，并根据任务是否可能重叠设计幂等和锁。

用 systemctl 检查 Unit= 是否真的指向目标

配置文件写完后，我会先检查 systemd 解析后的内容，再看 timer 记录的触发目标。下面的命令只读取 unit 信息，不需要把命令输出当成配置文件的一部分：

# 读取完整 unit，确认 [Timer] 中的 Unit= 没有写错
systemctl cat nightly-maintenance.timer

# 读取 systemd 当前解析出的目标字段
systemctl show nightly-maintenance.timer -p Unit -p Triggers -p NextElapseUSecRealtime

# 查看 timer 与被激活 service 的依赖关系
systemctl list-dependencies nightly-maintenance.timer

# 查看目标 service 的当前状态和最近一次失败原因
systemctl status maintenance-worker.service
journalctl -u maintenance-worker.service -n 50 --no-pager

检查时重点看三件事：timer 文件是否真的被 manager 重新加载，Unit= 是否是预期的 maintenance-worker.service，以及目标 service 是否仍处于 active。改完 unit 文件后可先执行 systemctl daemon-reload，再按需 systemctl enable --now nightly-maintenance.timer；启用 timer 不等于立刻执行一次 service。

我会怎样选择默认值或显式 Unit=

如果 timer 和 service 是稳定的一对同名文件，例如 backup.timer 与 backup.service，我会省略 Unit=，让默认规则保持简洁。如果调度器名称与任务名称不同、团队需要快速读懂绑定关系，或者后续可能替换目标 service，我会显式写 Unit=，并把目标名称纳入配置变更记录。

这就是这项配置最实用的边界：OnCalendar= 决定何时触发，Unit= 决定触发哪个 unit，[Service] 决定该 unit 如何运行。三者职责分开，排查时就不会在 timer 文件里寻找本应属于 service 的执行命令。

相关问题

不写 Unit= 时一定要创建同名 service 吗？

默认情况下是的，timer 会按去掉 .timer 后缀的名称寻找对应 service。若目标名称不同，就显式写 Unit=，不要依赖不存在的同名文件。

Unit= 可以指向 target 吗？

该选项指向 unit 名称，并不只限于 service；但 target 默认不会自行停用，若要被重复 timer 激活，需要结合 target 的生命周期配置。普通定时脚本通常直接绑定一个 service 更容易判断状态。

修改 Unit= 后为什么状态没有马上变化？

systemd manager 需要重新读取 unit 文件。执行 systemctl daemon-reload 后，再检查 timer 和目标 service；已经运行的旧任务不会因为改了配置就自动重启。