喜爱 systemd timers

对 systemd timers 的感知优势

• 许多评论者已经把大多数或全部 cron 任务迁移到了 systemd timers，尤其是备份和维护任务。
• 定时器可以是“persistent”的：如果系统在计划时间宕机，任务会在下次启动时运行一次。
• 与 systemd 单元集成后，可以通过 journalctl 为每个任务提供日志，方便手动触发（systemctl start …），并且在 timers 和 services 之间保持一致的环境。
• RandomizedOffsetSec= 和主机稳定抖动等特性有助于避免多台机器之间出现“thundering herd”式的负载峰值。
• 时间规范支持时区以及比传统 cron 更丰富的日历表达式。
• 一些人称赞服务端可用的安全/沙箱特性（命名空间、能力、随机 UID），认为对许多守护进程来说，它们比容器更简单。
• socket activation 被强调为一种强大的机制，可用于按需启动服务并对网络访问进行沙箱化。

与 cron（及其变体）的比较

• 对于简单的“每 N 分钟运行一次”任务，cron 被认为更简单，而且很直观（crontab -e，一行，搞定）。
• 其他人则认为 cron 众所周知地脆弱：环境不同、$PATH 问题、输出如果不显式捕获就会消失，以及调试很棘手。
• 一些人指出 cron 早已有 @reboot、类似 anacron 的补跑、RANDOM_DELAY 和 CRON_TZ 等扩展，认为 systemd 的优势没有宣传得那么大，而且在不同 cron 实现中也并不通用。

语法、配置与工具

• 关于 systemd 单元语法存在争论：有些人认为 INI 风格文件干净且简洁；另一些人觉得它们很难看，并希望使用 YAML、XML 或 TOML。
• 一些误解被纠正了（例如，= 两边允许空格；Environment= 可以包含多个变量）。
• NixOS 用户喜欢用 Nix 声明式地定义单元，带有类型检查和组合能力；批评者认为这种表示更丑，并怀念显式的 [Unit]/[Service]/[Timer] 分区。
• 需要单独的 .service 和 .timer 文件被认为既灵活，又令人烦躁地冗长。

可靠性、复杂性与批评

• 多条评论称赞 systemd 相比旧式 init 脚本和 cron 更稳健、文档更好。
• 也有人讲述了严重 bug（例如某个 logrotate timer 静默地从未运行），并指责 systemd 偶然复杂度过高，以及维护者对边缘情况反应迟缓。
• 更广泛的架构担忧包括：systemd 成为一个不断膨胀的巨型整体、对现有工具的“embrace and extend”，以及对供应商锁定的担忧。

生态、可移植性与替代方案

• 一些管理员在 BSD、Alpine 或非 systemd Linux 上更喜欢或必须使用 cron，或者使用替代调度器（mcron、自定义作业运行器）。
• 普遍共识是：在 systemd 系统上，timers 很棒；但 cron 依然有效，尤其是在 systemd 不存在或不受欢迎的地方。