你还没有足够热爱 systemd timers

背景

在 Linux 系统管理和自动化运维领域，cron 长期以来被视为定时任务调度的代名词。尽管 cron 可能并非实际执行动作的唯一守护进程，但正如 Patrick McKenzie 常指出的那样，cron jobs 是计算中最基本且极具实用性的原语之一。对于“每天执行一次”或“每月执行一次”这类常见需求，cron 提供的效用直观且显而易见。

然而，随着技术演进，到了 2026 年，我们拥有了更现代的替代方案。作者强烈建议，尽管 cron 依然广泛使用，但不应再将其作为调度任务的首选。相反，作者推崇 systemd timer（systemd 定时器），认为它是 cron 的现代、功能更强大的继任者。这篇文章旨在通过解读 systemd timer 的优势、配置方法及其背后的设计哲学，说服读者拥抱这一更现代的技术栈。

核心内容

为什么 cron 已显疲态？

作者首先列举了传统 cron 及其现代变体存在的几个核心痛点，这些问题在多年后的今天依然困扰着许多系统管理员：

1. 环境不确定性：cron 脚本执行时的 $PATH 设置往往含糊不清，导致脚本行为难以预测。
2. 输出黑洞：stdout 和 stderr 的输出通常无处可去，甚至可能被发送到主机的邮件系统中，这通常不是用户想要的结果。
3. 历史追踪困难：cron 的执行历史记录难以追溯和审查，出问题时排查成本高。
4. 语法晦涩难懂：虽然熟记 cron 调度语法可能让人产生一种掌控感，但类似 01,31 04,05 1-15 1,6 * 这样的表达式对人类来说既不可读也不直观。

相比之下，systemd timer 解决了上述所有问题，并提供了更清晰的执行上下文和日志记录。

systemd timer 基础入门

systemd timer 是一种单元（unit），用于按照特定时间表调度其他单元（通常是 service）。你可以将其逻辑上视为一个脚本的调度器。

1. 定义服务单元 (Service Unit)

首先需要一个目标服务。假设我们要创建一个名为 roulette.service 的服务，它有 1/10 的概率触发系统关机（仅用于演示）：

[Unit]
Description=1 in 10 chance to break your chains

[Service]
ExecStart=/usr/bin/env bash -c '[[ $(($RANDOM % 10)) == 0 ]] && systemctl poweroff || echo LIVE ANOTHER DAY'

优化建议：使用 ExecCondition 作者指出，Twitter 用户 HSVSphere 建议更优雅的方式是使用 ExecCondition 来处理条件执行。这种方式更紧密地集成在 systemd 中，能更清晰地表达意图：

[Unit]
Description=1 in 10 chance to break your chains

[Service]
ExecCondition=/run/current-system/sw/bin/bash -c '[[ $(($RANDOM % 10)) == 0 ]]'
ExecStart=/run/current-system/sw/bin/systemctl poweroff

这种方式会在日志中提供更清晰的反馈，例如： May 05 11:05:32 diesel systemd[3117]: Condition check resulted in 1 in 10 chance to break your chains being skipped.

此外，作者强调应充分利用 systemd 提供的原生选项，如使用 OnFailure= 在脚本失败时做出反应，或使用 Restart= 在临时故障时尝试恢复，而不是完全依赖自定义脚本。

2. 定义定时器单元 (Timer Unit)

将服务与定时器关联。创建一个与上述服务同名（roulette）但后缀为 .timer 的文件：

[Unit]
Description=impending destruction

[Timer]
OnCalendar=10:00

[Install]
WantedBy=timers.target

关联机制：默认情况下，timer 的 Unit= 设置会自动寻找同名后缀为 .service 的服务单元。如果需要执行不同名称的服务，可以显式指定 Unit=。

3. 关键注意事项

• 执行上下文：ExecStart= 默认不以 shell 命令形式运行。它期望的是一个可执行文件或解释器。例如，ExecStart=/usr/bin/echo Hello | /usr/bin/awk 是无效的，因为管道符 | 在 systemd 上下文中没有意义。
• 环境变量隔离：ExecStart= 默认不继承任何环境变量（除了系统管理器的一些默认值）。因此，$PATH 非常干净。使用 /usr/bin/env 是一种确保 systemctl 等命令可用的快捷方式，但也意味着你需要显式指定路径或使用 env 来保障兼容性。

4. 启动与管理

• 手动触发：你可以直接启动服务进行测试：

  systemctl start roulette
  

  注意：此服务没有 [Install] 部分，因此不能通过 enable 自动启动，定时器是使其一致运行的标准方式。

• 激活定时器：

  systemctl start roulette.timer
  

  当对 .timer 单元使用 start 时，它只是将定时器置于时钟上，并不会立即执行关联的服务。

• 检查状态：

  systemctl status roulette.timer
  

  输出会显示下一次触发的时间，例如： Trigger: Sat 2026-04-18 10:00:00 MDT; 35min left

• 开机自启： 由于 .timer 文件中定义了 WantedBy=timers.target，你可以启用它以在启动时自动激活：

  systemctl enable roulette.timer
  

时间表达式的艺术：Time Lord

定时器的核心在于如何表达时间表。systemd 支持两种主要形式：

1. 时间跨度 (Time Span)：重复的时间段。
2. 日历事件 (Calendar Event)：特定的时间戳。

作者推荐查阅 systemd.time(7) 手册页，这是编写定时器时的首选资源，其质量优于大多数博客文章。

此外，systemd 提供了命令行工具 systemd-analyze，用于验证和解释时间表达式。例如，解析经典的 cron 通配符表达式：

systemd-analyze calendar '*-*-* *:*:*'

输出示例：

Normalized form: *-*-* *:*:*
Next elapse: Sat 2026-04-18 16:44:26 MDT
(in UTC): Sat 2026-04-18 22:44:26 UTC
From now: 431ms left

这种工具化支持使得调试和验证复杂的调度逻辑变得直观且可靠。

关键要点

• 告别 Cron 的痛点：传统 cron 存在环境变量不可控、日志输出混乱、执行历史难追踪以及语法晦涩等问题。systemd timer 提供了更现代、更透明的解决方案。
• 单元关联机制：systemd timer 通过文件名关联服务单元（默认同名 .service），也可以通过 Unit= 配置显式指定。
• 原生条件执行：推荐使用 ExecCondition= 而非在脚本内部使用复杂的 shell 条件判断，这样能更好地利用 systemd 的日志记录和状态管理能力。
• 执行环境隔离：systemd 服务默认运行在干净的环境中，不继承用户环境变量。使用 /usr/bin/env 或绝对路径是确保命令可执行的关键。
• 定时器 vs 服务：systemctl start <timer> 仅激活调度器，不会立即执行服务；systemctl start <service> 立即执行一次。
• 强大的调试工具：利用 systemd-analyze calendar