为什么我推荐你使用 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，它不是单调的，用于指定未来的时间，可能是重复的，也可能不是。

表 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语句中使用的典型时间规格的例子：

表 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 吧~