使用 Cron 作业自动化重复任务

你编写了一个脚本来清理旧日志、备份数据库或预热缓存。手动运行时它工作得很完美。现在你需要它每天凌晨 2 点自动运行,无需你的干预。这就是 cron 发挥作用的地方。

Cron 仍然是现代 Linux 系统上调度脚本的标准工具。了解它的工作原理——以及何时使用替代方案——将使你免于静默失败和调试困扰。

什么是 Cron,它是如何工作的?

Cron 是内置于类 Unix 系统中的基于时间的作业调度器。后台守护进程读取配置文件(crontabs)并在指定的时间间隔执行命令。

有两种类型的 crontab:

• 用户 crontab:每个用户通过 crontab -e 维护自己的调度计划
• 系统 crontab:位于 /etc/crontab 和 /etc/cron.d/,包含用户名字段并处理系统级任务

Cron 守护进程每分钟检查这些文件,并运行任何调度时间与当前时间匹配的作业。

理解 Cron 语法

每个 cron 作业遵循五字段时间规范:

┌───────────── 分钟 (0-59)
│ ┌───────────── 小时 (0-23)
│ │ ┌───────────── 日期 (1-31)
│ │ │ ┌───────────── 月份 (1-12)
│ │ │ │ ┌───────────── 星期 (0-6, 星期日=0)
│ │ │ │ │
* * * * * /path/to/command

实际示例:

# 每晚凌晨 2 点运行备份脚本
0 2 * * * /home/deploy/scripts/backup.sh

# 每周日凌晨 3 点清理临时文件
0 3 * * 0 /usr/bin/find /tmp -type f -mtime +7 -delete

# 工作日的工作时间内每 15 分钟执行一次
*/15 9-17 * * 1-5 /home/deploy/scripts/health-check.sh

使用 crontab.guru 在部署前验证表达式。

使用 Cron 作业自动化任务的核心最佳实践

使用绝对路径

Cron 在最小化环境中运行。你的 PATH 可能不包含 /usr/local/bin 或自定义目录。始终指定完整路径:

# 错误 - 可能会静默失败
0 2 * * * backup.sh

# 正确
0 2 * * * /home/deploy/scripts/backup.sh

理解 Cron 的受限环境

Cron 不会加载你的 .bashrc 或 .profile。像 nvm、rbenv 或 pyenv 这样的版本管理器将不可用。要么显式地 source 它们,要么使用特定二进制文件的绝对路径。

添加日志记录和告警

如果没有输出重定向,cron 失败会被忽略:

0 2 * * * /home/deploy/scripts/backup.sh >> /var/log/backup.log 2>&1

对于关键作业,集成监控服务如 Healthchecks.io 或 Cronitor。

防止作业重叠

长时间运行的任务可能在下一次计划运行开始时仍在执行。使用 flock 防止重叠:

0 * * * * /usr/bin/flock -n /tmp/report.lock /home/deploy/scripts/generate-report.sh

应用最小权限原则

不要以 root 身份运行所有任务。为特定任务创建专用服务账户,并使用用户 crontab 而不是系统级配置。

注意时区和夏令时问题

Cron 使用系统时间。夏令时转换可能导致作业运行两次或完全跳过。对于关键调度,考虑使用 UTC。

Cron 与 Systemd Timers 的自动化对比

在基于 systemd 的发行版上,定时器提供了值得考虑的优势:

特性	Cron	Systemd Timers
日志记录	手动设置	内置 journald
错过的运行	跳过	可以补运行
依赖关系	无	完整的 systemd 集成
资源限制	手动	内置 cgroups

对于虚拟机上简单的主机级自动化,cron 工作得很好。当你需要依赖管理或更好的可观测性时,systemd 定时器值得额外的配置工作。

容器化和云原生环境中的 Cron 作业

传统的 cron 不能很好地适应容器。在应用程序旁边运行 cron 守护进程违反了每个容器单进程的原则。

更好的替代方案:

• Kubernetes CronJobs:为容器化工作负载提供原生调度,内置重试逻辑
• AWS EventBridge 或 GCP Cloud Scheduler:按计划触发 Lambda 函数或 Cloud Run 服务
• 应用级调度器:针对 Node.js 应用的工具如 node-cron

对于 Web 开发者,小型虚拟机上的 cron 仍然可以触发维护脚本、生成定期报告或预热缓存——即使你的主应用程序运行在其他地方。

总结

Cron 擅长简单的主机级自动化:备份脚本、日志轮转、证书续期检查和定期清理。它轻量级、普遍可用,不需要额外的基础设施。

当你需要分布式调度、容器编排或复杂的失败处理时,选择替代方案。概念保持不变——现代调度器借用 cron 的语法是有充分理由的。

从一个经过充分测试的作业开始,添加适当的日志记录,然后在此基础上构建。

常见问题

为什么我的 cron 作业手动运行正常但计划执行时失败?

Cron 在最小化环境中运行,不会加载你的 shell 配置文件如 .bashrc 或 .profile。这意味着你的自定义 PATH 设置和版本管理器不可用。通过对所有命令和脚本使用绝对路径来解决这个问题,或者在 cron 命令开始时显式地 source 你的环境文件。

如何调试不运行的 cron 作业?

首先,使用 systemctl status cron 检查 cron 是否正在运行。然后使用 crontab -l 验证你的 crontab 语法。通过使用 >> /path/to/log 2>&1 将输出重定向到文件来添加日志记录。检查 /var/log/syslog 或 /var/log/cron 中的系统日志以查找错误消息。还要确保你的脚本具有执行权限。

用户 crontab 和系统 crontab 有什么区别?

用户 crontab 通过 crontab -e 按用户管理,并以该用户身份运行命令。/etc/crontab 和 /etc/cron.d/ 中的系统 crontab 包含一个额外的用户名字段,指定运行命令的用户。系统 crontab 通常用于系统级维护任务,需要 root 访问权限才能编辑。

我应该为计划任务使用 cron 还是 systemd timers?

对于需要在各种类 Unix 系统上运行的简单、可移植的脚本,使用 cron。当你需要通过 journald 进行内置日志记录、补运行错过的任务、与其他服务的依赖管理或通过 cgroups 进行资源限制时,选择 systemd timers。Systemd timers 需要更多配置,但提供更好的可观测性。