登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

systemd.timer OnBootSec 与 OnUnitActiveSec 的周期触发配置方法

来源:17golang原创

时间:2026-11-15 00:37:29 351浏览 收藏

如果任务要求“机器启动 5 分钟后先跑一次,之后每次服务激活间隔 1 小时再跑”,systemd.timer 应该组合 OnBootSec= 和 OnUnitActiveSec=。前者以开机时间为起点,后者以被激活服务的最近一次启动为起点;两者都属于单调计时,不依赖时区和墙上时钟。

官方地址:https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

要点速览
  • OnBootSec=5min 负责开机后的首次触发。
  • OnUnitActiveSec=1h 负责服务每次激活后的下一次触发。
  • 改完单元要执行 daemon-reload,再用 list-timers --all 看下次时间。

先分清两个计时起点

OnBootSec= 是相对系统启动的延迟;例如机器启动后 5 分钟,计时器就具备触发条件。OnUnitActiveSec= 则跟着它激活的服务走:服务最近一次被激活后,再经过配置的时长触发下一轮。把两者放在同一个 timer 里,就能覆盖“首次延迟”和“以后固定间隔”两个需求。

这里不使用 Persistent=,因为它解决的是日历计时器错过执行后的补跑;也不使用 OnCalendar=,因为本文目标不是固定在每天某个钟点执行。

systemd.timer 中 OnBootSec 与 OnUnitActiveSec 指向同一服务的单调计时关系说明图
图1:systemd 单调计时起点关系说明图,不是截图或运行证据。

用 service 和 timer 组合出周期任务

假设脚本负责清理业务临时文件,先定义一个一次性服务:

[Unit]
# 让服务承担真正的工作,timer 只负责安排触发
Description=Clean application temporary files

[Service]
# oneshot 执行完即退出,适合被 timer 反复激活
Type=oneshot
ExecStart=/usr/local/bin/cleanup-app-tmp.sh

再创建同名的 timer:

[Unit]
# 这是调度单元,不直接执行清理脚本
Description=Run application cleanup periodically

[Timer]
# 开机后 5 分钟触发第一次
OnBootSec=5min
# 目标服务每次激活后,1 小时再触发下一次
OnUnitActiveSec=1h
# 明确绑定目标,避免依赖同名隐式匹配
Unit=cleanup-app-tmp.service

[Install]
# enable 时加入系统定时器目标
WantedBy=timers.target

文件名应分别是 /etc/systemd/system/cleanup-app-tmp.service 和 /etc/systemd/system/cleanup-app-tmp.timer。如果服务执行时间明显超过一个小时,要把“周期”理解为服务再次激活的时间基准,并为脚本增加并发锁,避免两次清理重叠。

重新加载并检查下次触发时间

# 让 systemd 重新读取刚修改的单元文件
sudo systemctl daemon-reload
# 设置开机自动启用,并立即启动这个 timer
sudo systemctl enable --now cleanup-app-tmp.timer
# 查看是否已加载、上次触发和下次触发
systemctl list-timers --all cleanup-app-tmp.timer
# 读取 timer 的最终属性,核对 OnBootSec 和 OnUnitActiveSec
systemctl cat cleanup-app-tmp.timer
# 查看被触发服务的执行日志
journalctl -u cleanup-app-tmp.service -n 50 --no-pager

看到 timer 出现在列表中,只能证明调度单元已加载;还要看 UNIT 是否是 cleanup-app-tmp.service,以及日志里是否真的出现了服务执行记录。单元文件改动后若漏掉 daemon-reload,磁盘上的新配置不会立即成为运行时配置。

systemd.timer 配置经 daemon-reload 后用 list-timers 和 journalctl 核对结果的关系说明图
图2:systemd.timer 配置与检查命令关系说明图,不是截图或运行证据。

几个容易误判的边界

现象应先判断什么处理方向
重启后没有补跑是否期待 Persistent 语义本文组合不负责错过任务补跑
休眠后触发时间变化是否需要计入挂起时长评估 WakeSystem= 的权限和硬件条件
服务重叠执行上一轮是否仍在运行在脚本或服务中做锁,或重新设计周期
必须每天 02:00 执行需求是不是墙上时钟改用 OnCalendar=,再单独评估时区和校时

单调计时器的好处是不会因时区切换而改变相对间隔,但它也不是精确实时调度器,仍会受到 AccuracySec= 等设置影响。需要休眠期间仍按时间唤醒机器时,官方文档建议结合 WakeSystem=,但它需要相应权限且不负责任务完成后的再次休眠。

常见问题

OnBootSec 和 OnUnitActiveSec 能同时写吗?

可以。多个计时表达式都成立时,timer 会在任一表达式到期时触发;本文利用它先满足开机延迟,再按目标服务的激活时间重复安排。

为什么只看到 timer 没看到服务日志?

先用 systemctl cat 核对 Unit=,再用 systemctl status cleanup-app-tmp.service 和 journalctl -u 查执行错误,别只看 timer 的下一次时间。

要固定每天某个时间,继续用这套配置吗?

不建议。固定钟点属于 OnCalendar= 的日历语义;本文的 OnBootSec 和 OnUnitActiveSec 更适合“启动后延迟”和“按服务激活间隔”这类相对时间。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>