Linux cron 和 systemd timer 怎样选择

Linux 定时任务出现问题时，真正让人犹豫的往往不是“每隔几分钟执行一次”怎么写，而是失败后去哪里找日志、任务是否依赖某个服务，以及机器关机错过时间后要不要补跑。简单脚本可以继续用 cron；如果任务需要服务级依赖、统一日志、开机补偿或更清晰的失败状态，systemd timer 通常更合适。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

选择标准可以先压缩成一句话：只需要“到点执行一个命令”就选 cron；需要把一次定时执行当成受 systemd 管理的服务，就选 systemd timer。

下面不把两者当成互斥的信仰问题，而是从一次常见的“任务看似执行了，但结果不对”故障现场开始比较。

先看两种调度模型的差异

cron 的核心是 crontab 中的时间字段匹配。常见写法是“分钟、小时、日、月、星期”五个字段，匹配后由 cron 守护进程执行命令。它短小、普遍、迁移成本低，但命令本身的环境、输出和依赖需要作者自己安排。

systemd timer 则通常由一个 .timer 单元触发对应的 .service 单元。触发规则写在 Timer 段，真正的命令、用户、工作目录和资源限制写在 Service 段。两者分开后，调度与任务职责更容易定位。

最小配置分别怎么写

如果任务只是每天凌晨生成一个目录清单，cron 足够直接。下面的注释说明了重定向和绝对路径的用途；真实部署时还要确认脚本可执行、环境变量完整。

# 每天 02:15 执行，使用绝对路径并把标准输出和错误写入同一日志
15 2 * * * /usr/local/bin/report-daily.sh >> /var/log/report-daily.log 2>&1

如果任务要依赖网络、单独配置运行用户，并希望从 journal 中按 unit 查看日志，可以拆成两个文件：

# /etc/systemd/system/report-daily.service
[Unit]
Description=生成每日目录清单
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
# 用固定用户运行，避免定时任务继承错误的登录环境
User=reporter
ExecStart=/usr/local/bin/report-daily.sh

# /etc/systemd/system/report-daily.timer
[Unit]
Description=每日目录清单定时器

[Timer]
# 日历触发；Persistent 让关机错过的日历触发在下次启动时补一次
OnCalendar=*-*-* 02:15:00
Persistent=true
Unit=report-daily.service

[Install]
WantedBy=timers.target

# 重新读取 unit 文件并启用定时器
sudo systemctl daemon-reload
sudo systemctl enable --now report-daily.timer
# 查看下一次触发时间与最近一次触发结果
systemctl list-timers report-daily.timer
sudo journalctl -u report-daily.service -n 50 --no-pager

日志、依赖和补偿决定了排障成本

cron 的输出通常需要显式重定向，或者依靠 cron 的邮件机制；当脚本内部又启动了子进程时，日志边界很容易变得模糊。它并不是不能做日志，而是日志路径、轮转、退出码处理要由任务自己组合。

systemd timer 的优势在于它触发的是 service。service 的标准输出可以进入 journal，依赖关系可以放在 [Unit] 段，任务执行用户和资源限制可以放在 [Service] 段。定时器本身只负责“何时触发”，任务失败则能直接从对应 service 的状态和日志入手。

Persistent=true 只适合需要补偿“关机期间错过的日历触发”的场景，它不是失败重试开关。脚本返回非零后，是否重试仍要由 service 的重启策略、幂等设计或外部队列决定。

四个容易误判的边界

第一，cron 的 */N 不一定表示严格的每 N 分钟。它是在分钟字段内按字段范围匹配，例如 */35 会命中每小时的 0 分和 35 分，不是跨小时连续计算的 35 分钟间隔。

第二，Persistent 不是“每次失败自动再跑”。它针对的是 timer 非活动期间错过的日历事件；程序本身失败后的补偿要另行设计。

第三，任务重叠要单独处理。cron 可能在上一次脚本仍未结束时再次启动；systemd timer 触发的 service 如果已经 active，默认不会凭空创建第二个实例。无论选择哪一个，都应该让脚本具备幂等性，或明确使用锁。

第四，依赖越多，越应该考虑 service 化。如果任务需要网络、挂载点、凭据目录或特定用户环境，systemd 的 unit 依赖和运行边界更容易集中管理；单行 cron 继续堆参数，最终会变成难以复盘的启动器。

实际选择可以记成一张表

最后的判断顺序是：先问任务是否只需要时间匹配；再问是否需要服务依赖和统一日志；最后确认错过执行、失败重试与重叠策略。只要后两项开始变复杂，就把 cron 单行升级为 systemd service 加 timer，排障时也会更容易把触发、执行和失败分开。

常见问题

cron 能不能记录退出码？

可以，但通常要在命令或脚本中显式记录，并配合日志重定向、邮件或监控。若希望直接按服务查看状态与日志，systemd service 更自然。

systemd timer 能完全替代 cron 吗？

不必强行替代。老系统、跨发行版安装脚本和极简单的用户任务继续使用 cron 很合理；在 systemd 已经是基础设施的服务器上，新任务优先 service 化通常更容易维护。