3.15 Cron 定时任务高级应用

预计阅读时间：18 分钟

学习目标

学完本章后，你将能够：

• 掌握 crontab 五字段语法及特殊字符串 @reboot、@daily 等
• 配置 cron 的环境变量并避免 PATH 陷阱
• 编写 systemd timer 替代传统 cron 任务
• 理解 anacron 的作用——解决"关机错过调度"问题
• 给 cron 任务配置日志记录与输出重定向
• 选择合适的定时任务方案（cron vs systemd timer vs anacron）

核心知识

• crontab 语法——分 时 日 月 周 命令，五个时间字段分别控制分钟(0-59)、小时（0-23）、日期（1-31）、月份（1-12）、星期（0-7，0/7=周日）
• 特殊字符串——@reboot（开机启动）、@daily / @midnight（每天0点）、@hourly、@weekly、@monthly、@yearly
• cron 环境变量——cron 在最小化 Shell 环境中执行任务，PATH 默认只有 /usr/bin:/bin，HOME 为当前用户家目录
• systemd timer——由 .timer + .service 两个 unit 组成，timer 触发 service 执行。支持单调（Monotonic）和日历（Calendar）两种时间表达
• anacron——为"不需要精确时间、只要在指定周期内运行一次"的场景设计。即使系统关机错过调度，恢复后自动补跑
• 日志与输出——cron 默认将 stdout/stderr 通过邮件发送给用户；systemd timer 输出由 journald 捕获；二者均可重定向到日志文件
• flock 防并发——使用 flock -n <lockfile> <command> 防止同一 cron 任务在前一次未完成时再次启动

知识关联

• 前置知识：2.12：systemd 深入「systemd 深入」——理解 systemd unit 是理解 timer 的前置；4.19：Shell 实战案例集「Shell 实战案例集」——cron 执行的大多是 Shell 脚本
• 后续影响：定时任务是运维自动化的基石——备份（3.13：备份策略与恢复 备份策略与恢复）、日志轮转、监控采集（3.12：系统监控与告警 系统监控方案）、证书续期（3.11：SSL/TLS 证书管理 SSL/TLS 证书管理）都依赖它
• 配套技术：2.7：日志与故障排查「日志与故障排查」——cron 输出关联到日志分析；4.1：Ansible 自动化「Ansible 自动化运维」——ansible 可批量管理各节点 crontab
• 在整个体系中的位置：这是从"手动管理"到"自动化运维"的关键枢纽。无论用 cron 还是 systemd timer，定时调度是每个生产系统必备的基础设施

原理讲解

1. cron——最经典的定时调度器

cron 是 Linux 中最古老的定时任务守护进程。它的工作模型是"永远在后台等待，每分钟醒来检查一次是否有需要触发的任务"：

crontab 文件层级：

用户 crontab 语法：

# ┌────── 分钟 (0-59)
# │ ┌───── 小时 (0-23)
# │ │ ┌───── 日期 (1-31)
# │ │ │ ┌───── 月份 (1-12)
# │ │ │ │ ┌───── 星期 (0-7，0/7=周日)
# * * * * * 命令

时间字段特殊符号：

2. systemd timer——cron 的现代替代

systemd timer 是 systemd 原生支持的定时机制。它的优势在于与 systemd 生态完全整合：

# 两种时间表达
# 1. 日历时间（OnCalendar）——类似 crontab 的精确时间点
OnCalendar=*-*-* 02:00:00     # 每天凌晨2点
OnCalendar=Mon..Fri 09:00:00  # 工作日上午9点
OnCalendar=*-*-1..7 00:00:00  # 每月前7天

# 2. 单调时间（OnUnitActiveSec）——相对启动/上次触发的时间间隔
OnBootSec=5min                 # 启动后5分钟
OnUnitActiveSec=1h             # 上次触发后1小时
OnUnitInactiveSec=30m          # 上次停止后30分钟

cron vs systemd timer 对比：

3. anacron——解决"关机错过"问题

anacron（anachronistic cron）不为"精确时间点"设计，而是"只要在周期内执行一次即可"。它记录上次执行时间戳到 /var/spool/anacron/，启动时检查是否超过周期；如果系统关机错过，下次开机后补跑：

# /etc/anacrontab 格式
# period delay job-identifier command
1       5     cron.daily    run-parts /etc/cron.daily
7       10    cron.weekly   run-parts /etc/cron.weekly
30      15    cron.monthly  run-parts /etc/cron.monthly

以上实际是大多数发行版的默认行为——cron 每小时执行 run-parts /etc/cron.hourly，而 cron.daily/weekly/monthly 调用的是 anacron。这确保了笔记本用户即使有大量离线时间也不会错过系统维护任务。

4. cron 的任务执行流程与运行环境

理解 cron 如何执行任务，是排查"单独跑正常、cron 里就失败"类问题的钥匙。一次完整执行包含五个阶段：

1. 调度匹配：crond 守护进程每分钟醒来，逐条比对 crontab 中的时间字段
2. 环境构造：crond 从 /etc/crontab、/etc/cron.d/* 以及用户 crontab 头部的环境变量行构造最小环境（HOME=用户家目录，PATH=/usr/bin:/bin，SHELL=/bin/sh）
3. fork + exec：以任务所属用户的身份 fork 子进程执行命令（不经过登录 shell，/etc/profile、~/.bashrc 都不加载）
4. 输出捕获：stdout/stderr 被捕获，若有输出则通过 sendmail 发给 MAILTO 指定的邮箱
5. 日志记录：在 syslog 中写入一条 CMD 记录

# 观察 cron 的执行痕迹（第 5 阶段）
grep CRON /var/log/syslog | tail -5
# 输出: Jul 30 02:00:01 host CRON[1234]: (root) CMD (/usr/local/bin/backup.sh)
#       Jul 30 02:00:02 host CRON[1235]: (root) CMD (test -x /usr/sbin/anacron && ...)

# 验证"不加载交互式环境"这一事实：
# 把以下两行加入 crontab，对比输出即可证明
# * * * * * echo "PATH=$PATH" >> /tmp/cron-env.txt
# * * * * * whoami >> /tmp/cron-env.txt
# 手工执行 echo $PATH 的结果完全不同

5. 定时任务安全：访问控制与最小权限

cron 提供两层访问控制文件：/etc/cron.allow（白名单，存在则只有名单内用户可用 crontab）和 /etc/cron.deny（黑名单）。两个文件都不存在时，多数发行版默认只允许 root 使用 crontab——这正是很多教程里"普通用户 crontab -e 报权限不足"的原因。

# 白名单：只有列出的用户可以创建 crontab
# /etc/cron.allow
root
alice

# 黑名单：禁止特定用户（当 cron.allow 不存在时生效）
# /etc/cron.deny
guest

# 校验当前用户是否有 crontab 权限
crontab -l || echo "no crontab or not permitted"

# 安全建议：
# 1. 系统任务统一放 /etc/crontab 或 /etc/cron.d/，由 root 管理
# 2. 业务任务创建专用低权限用户执行，避免全部用 root
# 3. 敏感任务（备份、证书续期）优先放 /etc/cron.d/ 便于审计

示例代码

1. 基础 crontab 实例

# 每分钟执行 —— 调试用
*/1 * * * * /usr/local/bin/health-check.sh

# 每天凌晨2:30执行备份（带日志）
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# 工作日9-18点每小时检查一次
0 9-18 * * 1-5 /usr/local/bin/check-service.sh

# 每月1号和15号凌晨3点清理
0 3 1,15 * * /usr/local/bin/cleanup.sh

# 每月最后一天执行（次月1日前一天）
0 0 28-31 * * [ "$(date +\%d -d tomorrow)" = "01" ] && /usr/local/bin/monthly-report.sh

# @reboot —— 开机启动（不是用户登录）
@reboot /usr/local/bin/startup-tasks.sh

2. 完整 crontab 环境变量设置

# /etc/crontab 环境变量 —— 避免"命令找不到"陷阱
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=admin@example.com
HOME=/root
LOGNAME=root

# 系统 crontab 需指定用户
30 2 * * * root /usr/local/bin/backup.sh

3. systemd timer 完整实例——备份任务

# /etc/systemd/system/backup.service
[Unit]
Description=Daily backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
StandardOutput=journal
StandardError=journal

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily at 2am
Requires=backup.service

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true                  # 错过则补跑
RandomizedDelaySec=300           # 随机延迟0-5分钟
Unit=backup.service

[Install]
WantedBy=timers.target

# 启用
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer  # 输出: Created symlink /etc/systemd/system/timers.target.wants/backup.timer
systemctl list-timers  # 输出: NEXT          LEFT     LAST PASSED UNIT            ACTIVATES
systemctl status backup.timer  # 输出: ● backup.timer - Run backup daily at 2am

4. 日志配置与调试

# 方法1：cron 输出重定向到文件
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# 方法2：用 logger 发送到 syslog
30 2 * * * /usr/local/bin/backup.sh 2>&1 | logger -t backup

# 方法3：systemd timer 通过 journald 查看
journalctl -u backup.service  # 输出: -- Logs begin at ..., end at ... --
journalctl -u backup.timer  # 输出: -- Logs begin at ..., end at ... --
journalctl --since "1 hour ago" -u backup.service

# 方法4：cron 自身日志
grep CRON /var/log/syslog  # 输出: Jul 30 02:00:01 host CRON[1234]: (root) CMD (/usr/local/bin/backup.sh)
# Ubuntu/Debian 在 /var/log/syslog；RHEL 系在 /var/log/cron

# 调试技巧：手工跑一次测试
sudo -u www-data /usr/local/bin/script.sh

# 用 flock 防并发
30 2 * * * flock -n /tmp/backup.lock /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

5. 高级 crontab 技巧

# 错峰执行：同一分钟大量任务并发会拉高负载，分散到不同分钟
# 不好的写法（10 个任务都在 0 分触发）
0 * * * * /opt/jobs/clean-tmp.sh
0 * * * * /opt/jobs/sync-cache.sh
# 更好的写法：按分钟错开
0 * * * * /opt/jobs/clean-tmp.sh
5 * * * * /opt/jobs/sync-cache.sh
10 * * * * /opt/jobs/rotate-log.sh

# 随机化启动时间：避免整点雷击（1-59 分钟内随机挑一分执行）
# 注意：cron 的 SHELL=/bin/sh（dash）没有 $RANDOM，用 date +%N 生成随机纳秒数
# （10# 前缀防止前导零被当作八进制；crontab 中的 % 需转义为 \%）
*/5 * * * * sleep $((10#$(date +\%N) % 60)) && /opt/jobs/heartbeat.sh

# @reboot 深入：延迟执行，等待网络/服务就绪
@reboot sleep 30 && /usr/local/bin/startup-tasks.sh

# 每月最后一天 23:30（次月 1 日判断法，% 需转义）
30 23 28-31 * * [ "$(date +\%d -d tomorrow)" = "01" ] && /usr/local/bin/end-of-month.sh

# 每季度首日（1/4/7/10 月的 1 号）
0 4 1 1,4,7,10 * /usr/local/bin/quarterly-report.sh

# 周报：每周一早上 8 点
0 8 * * 1 /usr/local/bin/weekly-summary.sh

# 任务超时保护：timeout 命令兜底，防止脚本死循环
30 2 * * * timeout 3600 /usr/local/bin/heavy-job.sh >> /var/log/heavy.log 2>&1

6. anacron 深入配置

# /etc/anacrontab 完整格式说明
# period delay job-identifier command
#  └周期天数 └延迟分钟 └任务ID(唯一)  └实际命令

1       5     cron.daily    run-parts /etc/cron.daily
7       10    cron.weekly   run-parts /etc/cron.weekly
30      15    cron.monthly  run-parts /etc/cron.monthly

# 自定义 anacron 任务：每周至少运行一次数据归档
# 7 20 data-archive /usr/local/bin/archive.sh >> /var/log/archive.log 2>&1

# anacron 关键配置（/etc/default/anacron）
# RANDOM_DELAY=45       # 补跑时随机延迟 0-45 分钟，避免多机同时补跑
# START_HOURS_RANGE=3-22  # 只在 3:00-22:00 之间检查补跑

# 查看上次运行时间戳（anacron 用它判断是否到期）
cat /var/spool/anacron/cron.daily
# 输出: 20260730   ← 上次执行的日期，超过周期天数则触发补跑

# 手动强制触发
anacron -f -d             # -f 忽略时间戳强制运行，-d 前台调试模式

# 查看 anacron 是否活跃
systemctl status anacron.timer
# 输出: ● anacron.timer - Trigger anacron every hour
#        Active: active (waiting)

7. 脚本幂等性与健壮性

定时任务可能因重叠执行、手工重跑、故障重试而多次运行。一个健壮的脚本必须幂等——无论执行多少次，最终结果一致，且不会造成副作用。这与 Ansible 等配置管理工具的幂等性理念一致：不是"重复执行会怎样"，而是"重复执行也不该出事"。

# 幂等写法示例：备份脚本（同名文件直接覆盖即可）
#!/bin/bash
set -euo pipefail                      # 严格模式：变量未定义/管道失败立即退出

# 防并发：exec 打开锁文件并持有 fd 9，flock 加锁后主逻辑全程持锁
# （不要用 flock -c "command"，子 shell 退出即释放锁，主逻辑等于没锁）
LOCKFILE=/tmp/backup.lock
exec 9> "$LOCKFILE"
if ! flock -n 9; then
    echo "$(date) backup already running, skip" >> /var/log/backup.log
    exit 0                             # 幂等：直接退出，而不是报错
fi
echo $$ >&9                            # 锁内记录持有者 PID，方便排查

# 幂等示例：插入唯一记录（重复执行不产生重复数据）
# INSERT ... ON DUPLICATE KEY UPDATE / INSERT ... ON CONFLICT DO NOTHING

# 幂等示例：创建目录与文件（已存在则跳过）
mkdir -p /var/lib/myapp                # 已存在不报错

# 失败可重试：任务完成后写标记文件
if [ -f /var/run/myapp.done ] && [ -z "${FORCE_RUN:-}" ]; then
    echo "already done, pass" && exit 0
fi
# ... 主逻辑 ...
touch /var/run/myapp.done

8. 定时任务排错流程

任务不执行或执行异常时，按以下顺序排查，避免在错误层面浪费时间：

# 第一步：确认 crontab 真的在（语法正确）
crontab -l                    # 或 crontab -e 检查当前用户任务
systemctl status cron         # cron 服务本身是否在运行

# 第二步：确认调度时间正确（最常见的低级错误）
# 用 crontab.guru 校验表达式语义：
# 0 2 * * *     每天凌晨2点 ✓
# * 2 * * *     每天2点内每分钟 ✗（往往不是本意）
date                          # 核对服务器时区与时间（UTC vs CST 差 8 小时）

# 第三步：确认 cron 真的触发了
grep "CMD" /var/log/syslog | grep backup | tail -5
# 没有记录 → 调度/权限问题；有记录 → 命令本身问题，进第四步

# 第四步：手工以相同身份执行，对比输出
sudo -u root /usr/local/bin/backup.sh
sudo -u www-data /usr/local/bin/backup.sh    # 以任务实际用户身份跑
# 手工能跑、cron 不能跑 → PATH/环境问题，检查脚本内是否用了相对路径

# 第五步：检查输出捕获与邮件
ls /var/mail/root              # 邮件默认存放位置，MAILTO 未设置时
grep "backup" /var/log/mail.log 2>/dev/null

# 第六步：检查脚本自身日志与退出码
echo "exit code: $?"           # cron 失败时退出码通常为 1
# 脚本中每步都打日志，避免"黑盒"：
# set -x 调试模式输出每一条执行语句

常见错误

最佳实践

练习题

1. （概念）cron 的 @reboot 和 systemd timer 的 OnBootSec 有什么区别？各自的适用场景是什么？
2. （概念）anacron 解决了 cron 的什么不足？在什么场景下应该优先使用 anacron？
3. （实操）编写一个 crontab 条目：每个工作日上午 9:05 执行 /usr/local/bin/check-disk.sh，输出追加到 /var/log/disk-check.log，错误也一并追加。
4. （实操）创建一个 systemd timer：每天凌晨 3:30 执行 /usr/local/bin/db-backup.sh，要求支持错过补跑（Persistent=true）。写出完整的 .service 和 .timer 文件及启用命令。
5. （探究 🔍）查看你当前系统的 /etc/anacrontab、/etc/crontab 和 systemctl list-timers 的输出。回答：你系统上的 cron.daily 任务实际上是由 cron 还是 anacron 触发的？如何验证？systemd timer 当前有哪些活跃条目？

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

定时任务是系统自动化的基础设施。cron 覆盖面最广、生态最成熟；systemd timer 更现代、功能更强，适合与 systemd 生态深度整合的场景；anacron 专门解决"不精确但必须执行"的需求。选型要看对精度、依赖、日志和可移植性的要求。

速查表

学习路径：掌握本章后，继续学习 4.19：Shell 实战案例集「Shell 实战案例集」编写健壮的 cron 执行脚本 → 3.13：备份策略与恢复「备份策略与灾难恢复方案」设计完整备份体系 → 4.8：集中式日志管理「集中式日志管理方案」统一收集 cron 执行日志。

延伸阅读