为什么我推荐你使用 systemd timer 替代 cronjob?

概述

前几天在使用 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 吧~???

参考资料

三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.

本站文章如无特殊说明，均为本站原创，如若转载，请注明出处：为什么我推荐你使用 systemd timer 替代 cronjob? - Python技术站