概述
前几天在使用 Terraform + cloud-init 批量初始化我的实验室 Linux 机器。正好发现有一些定时场景需要使用到 cronjob, 进一步了解到 systemd timer 完全可以替换 cronjob, 并且 systemd timer 有一些非常有趣的功能。
回归话题：为什么我推荐你使用 systemd timer 替代 cronjob? 因为相比 cronjob, systemd timer 有这些优势：
- 可以覆盖 cronjob 的所有功能
- 统一日志收集到 systemd 日志
- 针对时间精确度更详细的配置项
- 除了定时场景，还支持基于 event 的触发
- 相比 cronjob 更灵活的语法
- 更丰富的使用/运维命令集
接下来我们一一介绍。
首先我们通过系统自带的 timer 来熟悉这个新玩意。
系统自带的 timer
当 Ubuntu 或任何基于 systemd 的发行版安装在一个新系统上时，它会创建几个 timer，作为任何 Linux 主机后台的系统维护程序的一部分。这些 timer 会触发普通维护任务所需的事件，比如更新系统数据库、清理临时目录、切割日志文件等等。
我们使用systemctl status *timer命令列出我的主机上的所有 timer:
casey@casey-Virtual-Machine:~$ systemctl status *timer
● plocate-updatedb.timer - Update the plocate database daily
Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2023-04-04 16:49:49 CST; 19s ago
Trigger: Wed 2023-04-05 00:40:16 CST; 7h left
Triggers: ● plocate-updatedb.service
4 月 04 16:49:49 casey-Virtual-Machine systemd[1]: Started Update the plocate database daily.
● fwupd-refresh.timer - Refresh fwupd metadata regularly
Loaded: loaded (/lib/systemd/system/fwupd-refresh.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2023-04-04 16:49:49 CST; 19s ago
Trigger: Wed 2023-04-05 01:54:51 CST; 9h left
Triggers: ● fwupd-refresh.service
4 月 04 16:49:49 casey-Virtual-Machine systemd[1]: Started Refresh fwupd metadata regularly.
● update-notifier-motd.timer - Check to see whether there is a new version of Ubuntu available
Loaded: loaded (/lib/systemd/system/update-notifier-motd.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2023-04-04 16:49:50 CST; 19s ago
Trigger: Sat 2023-04-08 03:19:02 CST; 3 days left
Triggers: ● update-notifier-motd.service
4 月 04 16:49:50 casey-Virtual-Machine systemd[1]: Started Check to see whether there is a new version of Ubuntu available.
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2023-04-04 16:49:49 CST; 19s ago
Trigger: Tue 2023-04-04 17:58:23 CST; 1h 8min left
Triggers: ● fstrim.service
Docs: man:fstrim
4 月 04 16:49:49 casey-Virtual-Machine systemd[1]: Started Discard unused blocks once a week.
...
每个 timer 至少有六行信息与之相关：
- 第一行是 timer 的文件名和对其用途的简短描述。
- 第二行显示 timer 的状态，它是否被加载，timer unit 文件的完整路径，以及供应商的预设。
- 第三行显示其活动状态，包括 timer 开始活动的日期和时间。
- 第四行包含 timer 下次被触发的日期和时间，以及直到触发发生的大致时间。
- 第五行显示由 timer 触发的事件或服务的名称。
- 一些（但不是全部）systemd unit 文件有指向相关文档的指针。如上面的 Docs: man:fstrim
- 最后一行是 timer 所触发的服务的最新实例的日志条目。
创建 timer
优势之一：统一日志收集到 systemd 日志
为了更快了解 timer, 我们创建自己的 service unit 和 timer unit 来触发。
具体用途为：每周定期更新 tailscale 的版本。
首先，创建 tailscale update 服务，如下：
[Unit]
Description=Tailscale update
Wants=tailscale-weekly-update.timer
[Service]
Type=oneshot
ExecStart=/usr/bin/tailscale update -yes
[Install]
WantedBy=multi-user.target
然后，创建 tailscale update timer, 如下：
[Unit]
Description=Tailscale update
Requires=tailscale-weekly-update.service
[Timer]
Unit=tailscale-weekly-update.service
OnCalendar=weekly
[Install]
WantedBy=timers.target
最后，启用 timer:
systemctl enable tailscale-weekly-update.timer
这样就可以了，但是为了演示，执行：systemctl start tailscale-weekly-update.service 手动运行一次。
输出会直接集成到 systemd 日志里，并可以通过 journalctl 查看：（包含手动执行日志，和后续自动定期执行的日志）
$ sudo journalctl -S "2023-03-29 00:00:00" -u tailscale-weekly-update.service
4 月 02 09:14:28 casey-Virtual-Machine systemd[1]: Starting Tailscale node agent...
4 月 02 09:14:30 casey-Virtual-Machine tailscale[6898]: 获取：1 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease
4 月 02 09:14:30 casey-Virtual-Machine tailscale[6898]: 获取：2 https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 Packages [7,853 B]
4 月 02 09:14:32 casey-Virtual-Machine tailscale[6898]: 已下载 13.9 kB，耗时 1 秒 (14.4 kB/s)
4 月 02 09:14:32 casey-Virtual-Machine tailscale[6898]: 正在读取软件包列表。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 正在读取软件包列表。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 正在分析软件包的依赖关系树。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 正在读取状态信息。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 下列软件包将被升级：
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: tailscale
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 升级了 1 个软件包，新安装了 0 个软件包，要卸载 0 个软件包，有 4 个软件包未被升级。
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 需要下载 23.0 MB 的归档。
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 解压缩后将会空出 1,024 B 的空间。
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 获取：1 https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 tailscale amd64 1.38.3 [23.0 MB]
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 无法初始化前端界面：Dialog
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: （系统未设定 TERM 环境变量，所以对话框界面将不可使用。)
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 返回前端界面：Readline
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 无法初始化前端界面：Readline
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: （这个界面要求可控制的 tty。)
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 返回前端界面：Teletype
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: dpkg-preconfigure: 重新开启标准输入失败：
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7101]: 已下载 23.0 MB，耗时 40 秒 (577 kB/s)
4 月 02 09:15:14 casey-Virtual-Machine tailscale[7101]: [729B blob data]
4 月 02 09:15:14 casey-Virtual-Machine tailscale[7101]: 准备解压 .../tailscale_1.38.3_amd64.deb ...
4 月 02 09:15:14 casey-Virtual-Machine tailscale[7101]: 正在解压 tailscale (1.38.3) 并覆盖 (1.38.2) ...
4 月 02 09:15:15 casey-Virtual-Machine tailscale[7101]: 正在设置 tailscale (1.38.3) ...
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: Running kernel seems to be up-to-date.
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: Services to be restarted:
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: systemctl restart tailscale-weekly-update.service
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: No containers need to be restarted.
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: No user sessions are running outdated binaries.
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: No VM guests are running outdated hypervisor (qemu) binaries on this host.
4 月 02 09:15:24 casey-Virtual-Machine systemd[1]: tailscale-weekly-update.service: Deactivated successfully.
4 月 02 09:15:24 casey-Virtual-Machine systemd[1]: Finished Tailscale node agent.
4 月 02 09:15:24 casey-Virtual-Machine systemd[1]: tailscale-weekly-update.service: Consumed 6.317s CPU time.
$ sudo journalctl -S "2023-03-29 00:00:00" -u tailscale-weekly-update.timer
4 月 02 09:14:28 casey-Virtual-Machine systemd[1]: Started Tailscale node agent.
4 月 02 20:01:52 casey-Virtual-Machine systemd[1]: tailscale-weekly-update.timer: Deactivated successfully.
4 月 02 20:01:52 casey-Virtual-Machine systemd[1]: Stopped Tailscale node agent.
如上面的日志，可以很方便地检查 timer 和服务的状态。
在日志这方面，你不需要做任何特别的事情，就可以使tailscale-weekly-update.service unit 中的ExecStart触发器的STDOUT存储在日志中。这都是使用 systemd 运行服务的一部分。
Systemd timer 时间精度
优势之一：针对时间精确度更详细的配置项
从上面日志，如果细看，timer 不会在:00秒的时候准确触发，甚至不会在上一个实例的一分钟内准确触发。这是故意的，但如果有必要的话，可以覆盖它的默认配置。
这种行为的原因是为了防止多个服务在完全相同的时间被触发。例如，你可以使用时间规格，如每周、每天，等等。这些快捷方式都被定义为在它们被触发的那一天的 00:00:00 时触发。当多个 timer 被这样指定时，它们很有可能会试图同时启动。
systemd timer 被有意设计成在指定时间内随机触发，以防止同时触发。它们在一个时间窗口内半随机地触发。根据systemd.timer手册，这个触发时间相对于所有其他定义的 timer 单位来说，保持在一个稳定的位置。
大多数时候，这种概率性的触发时间是没有问题的。当安排备份等任务运行时，只要它们在非工作时间运行，就不会有问题。一个系统管理员可以选择一个确定的开始时间，如典型的 cronjob 规范中的 01:05:00，以不与其他任务冲突，但有很大范围的时间值可以达到这个目的。启动时间中的一分钟随机性通常是不相关的。
然而，对于某些任务，精确的触发时间是一个绝对要求。对于这些任务，你可以通过在 timer unit 文件的 Timer 部分添加这样的配置来指定更高的触发时间跨度精度（如精度在一微秒内）：
AccuracySec=1us
时间跨度可用于指定所需的精度，以及为重复性或一次性事件定义时间跨度。它可以识别以下单位：
- usec, us, µs
- msec, ms
- seconds, second, sec, s
- minutes, minute, min, m
- hours, hour, hr, h
- days, day, d
- weeks, week, w
- months, month, M （定义为 30.44 天）
- years, year, y （定义为 365.25 天）
/usr/lib/systemd/system中的所有默认 timer 都指定了一个更大的精度范围，因为精确的时间并不关键。看看系统创建的 timer 中的一些规格：
$ grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/plocate-updatedb.timer:AccuracySec=20min
/usr/lib/systemd/system/snapd.snap-repair.timer:AccuracySec=10min
Timer 类型
优势之一：除了定时场景，还支持基于 event 的触发
systemd timer 具有 cron 所不具备的其他功能，cron 只在特定的、重复的、实时的日期和时间触发。但是，一个 timer 可以被配置为在系统启动后，或在启动后，或在某个定义的服务 unit 激活后的特定时间内触发。这些被称为单调性 timer。单调指的是一个持续增加的计数或序列。这些 timer 不是持久的，因为它们在每次启动后都会重置。
表 1 列出了单调的 timer 以及每个 timer 的简短定义，还有 "OnCalendar" timer，它不是单调的，用于指定未来的时间，可能是重复的，也可能不是。
| Timer | 单调性 | 定义 |
|---|---|---|
| OnActiveSec= | X | 这定义了一个相对于 timer 被激活的时刻的 timer。 |
| OnBootSec= | X | 这定义了一个相对于机器启动时间的 timer。 |
| OnStartupSec= | X | 这定义了一个相对于服务管理器首次启动时间的计时器。对于系统 timer unit，这与OnBootSec=非常相似，因为系统服务管理器通常在启动时很早就启动。当配置在每个用户服务管理器中运行的单元时，它主要是有用的，因为用户服务管理器一般只在第一次登录时启动，而不是在启动时。 |
| OnUnitActiveSec= | X | 这定义了一个相对于要激活的 timer 最后一次被激活的时间。 |
| OnUnitInactiveSec= | X | 这定义了一个相对于要激活的 timer 最后被停用的时间的定时器。 |
| OnCalendar= | 这就用日历事件表达式定义了实时 timer。更多关于日历事件表达式的语法信息请参见systemd.time(7)。否则，其语义与OnActiveSec=及相关设置类似。这个 timer 是最像那些与 cron 服务一起使用的 timer。 |
表 1: systemd timer 定义
单调 timer 的时间跨度可以使用与前面提到的AccuracySec语句相同的快捷名称，但 systemd 将这些名称规范化为秒。例如，你可能想指定一个 timer，在系统启动 5 天后触发一次事件，可以这样写： OnBootSec=5d。如果主机在2020-06-15 09:45:27启动，timer 将在2020-06-20 09:45:27或之后一分钟内触发。
Calendar event 定义
优势之一：相比 cronjob 更灵活的语法
Calendar event 定义是在所需的重复时间触发 timer 的关键部分。首先看一下OnCalendar设置中使用的一些规格。
systemd 及其 timer 使用的时间和日期规格与 crontab 中使用的格式不同。它比 crontab 更灵活，允许以at命令的方式模糊日期和时间。
使用OnCalendar=的 systemdtimer 的基本格式是DOW YYYY-MM-DD HH：MM：SS。DOW（星期）是可选的，其他字段可以使用星号（*）来匹配该位置的任何值。所有日历时间形式都被转换为规范化的形式。如果没有指定时间，则假定其为 00:00:00。如果没有指定日期但指定了时间，那么下一个匹配可能是今天或明天，这取决于当前的时间。名称或数字可用于月份和星期。可以指定每个单位的逗号分隔的列表。单位范围可以在开始和结束值之间用...来指定。
有几个有趣的选项用于指定日期。波浪号（~）可以用来指定该月的最后一天或该月最后一天之前的指定天数。"/"可以用来指定一周中的某一天作为修饰语。
下面是一些在OnCalendar语句中使用的典型时间规格的例子：
| Calendar event 定义 | 描述 |
|---|---|
| DOW YYYY-MM-DD HH:MM:SS | |
| *-*-* 00:15:30 | 每年的每个月的每一天，在午夜后的 15 分钟 30 秒。 |
| Weekly | 每个星期一的 00:00:00 |
| Mon *-*-* 00:00:00 | 与每周相同 |
| Mon | 与每周相同 |
| Wed 2020-*-* | 2020 年的每个星期三，00:00:00 |
| Mon..Fri 2021-*-* | 2021 年的每个工作日的 00:00:00 |
| 2023-6,7,8-1,15 01:15:00 | 2023 年 6 月、7 月和 8 月的 1 日和 15 日凌晨 01:15:00 |
| Mon *-05~03 | 任何一年的 5 月的下一个星期一，也是月末的第三天。 |
| Mon..Fri *-08~04 | 任何年份的 8 月底前的第 4 天，如果该天也是工作日，则为 8 月底。 |
| *-05~03/2 | 从五月底开始的第三天，两天后再来一次。每年都会重复。请注意，这个表达式使用了（~）。 |
| *-05-03/2 | 五月的第三天，然后在五月的其余时间里每隔一天。每年重复一次。注意，这个表达式使用了破折号（-）。 |
表 2: 示例OnCalendar event 定义
测试 calendar 定义
优势之一：更丰富的使用/运维命令集
systemd 提供了一个很好的工具来验证和检查 timer 中的日历时间事件规范。systemd-analyze calendar工具解析了一个日历时间事件规范，并提供了规范化的形式以及其他有趣的信息，比如下一个 "elapse"（即匹配）的日期和时间，以及达到触发时间前的大致时间。
首先，看一下未来的一个没有时间的日期：
$ systemd-analyze calendar 2030-06-17
Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
Next elapse: Mon 2030-06-17 00:00:00 CST
(in UTC): Sun 2030-06-16 16:00:00 UTC
From now: 7 years 2 months left
现在添加一个时间。在这个例子中，日期和时间作为非相关实体被单独分析：
$ systemd-analyze calendar 2030-06-17 15:21:16
Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
Next elapse: Mon 2030-06-17 00:00:00 CST
(in UTC): Sun 2030-06-16 16:00:00 UTC
From now: 7 years 2 months left
Original form: 15:21:16
Normalized form: *-*-* 15:21:16
Next elapse: Wed 2023-04-05 15:21:16 CST
(in UTC): Wed 2023-04-05 07:21:16 UTC
From now: 21h left
要把日期和时间作为一个 unit 来分析，需要用引号把它们括起来。
$ systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16
Next elapse: Mon 2030-06-17 15:21:16 CST
(in UTC): Mon 2030-06-17 07:21:16 UTC
From now: 7 years 2 months left
现在测试表 2 中的条目。选一个复杂的：
$ systemd-analyze calendar "2023-6,7,8-1,15 01:15:00"
Original form: 2023-6,7,8-1,15 01:15:00
Normalized form: 2023-06,07,08-01,15 01:15:00
Next elapse: Thu 2023-06-01 01:15:00 CST
(in UTC): Wed 2023-05-31 17:15:00 UTC
From now: 1 month 26 days left
让我们看一个例子，在这个例子中，我们列出了时间戳表达式的下五个执行时间：
$ systemd-analyze calendar --iterations=5 "Mon *-05~3"
Original form: Mon *-05~3
Normalized form: Mon *-05~03 00:00:00
Next elapse: Mon 2023-05-29 00:00:00 CST
(in UTC): Sun 2023-05-28 16:00:00 UTC
From now: 1 month 23 days left
Iter. #2: Mon 2028-05-29 00:00:00 CST
(in UTC): Sun 2028-05-28 16:00:00 UTC
From now: 5 years 1 month left
Iter. #3: Mon 2034-05-29 00:00:00 CST
(in UTC): Sun 2034-05-28 16:00:00 UTC
From now: 11 years 1 month left
Iter. #4: Mon 2045-05-29 00:00:00 CST
(in UTC): Sun 2045-05-28 16:00:00 UTC
From now: 22 years 1 month left
Iter. #5: Mon 2051-05-29 00:00:00 CST
(in UTC): Sun 2051-05-28 16:00:00 UTC
From now: 28 years 1 month left
这应该给你足够的信息来开始测试你的OnCalendar时间规格。
总结
systemd timer 可以用来执行与 cron 工具相同类型的任务，但在触发事件的 calendar 和单调的时间规格方面提供了更多的灵活性。
除此之外，systemd timer 还有的优势包括：
- 统一日志收集到 systemd 日志
- 针对时间精确度更详细的配置项
- 更丰富的使用/运维命令集
快去尝试迁移你的 cronjob 到 systemd timer 吧~???
参考资料
- Use systemd timers instead of cronjobs
- Fedora 的 systemd 指南
- Fedora 的 systemd cheat sheet
以上就是推荐使用systemd timer替代0cronjob的详细内容，更多关于systemd timer替代cronjob的资料请关注编程网其它相关文章！
