Linux 定时任务说明：Cron vs Systemd Timer 的选择与实战

说明： 本文为配置思路与示例整理，不代表作者已在自己的服务器上逐项验证全部命令。执行涉及公网暴露、账户权限、数据删除或服务重启的操作前，请先备份，并结合官方文档与实际环境核验。

在 Linux 运维和开发中，定时任务是不可或缺的能力——自动备份数据库、定时清理日志、周期性监控服务状态，都依赖定时任务来完成。然而很多开发者只停留在 crontab -e 的基础用法上，对 cron 的高级特性和现代替代方案 systemd timer 了解甚少。

本文将系统对比 Cron 和 Systemd Timer，从基础用法到较完整的建议，帮你做出正确的技术选型。

一、传统 Cron：经典但不完美

1.1 Cron 的基本语法

Cron 表达式由 5 个字段组成，从左到右依次为：

┌───────────── 分钟 (0-59)
│ ┌───────────── 小时 (0-23)
│ │ ┌───────────── 日 (1-31)
│ │ │ ┌───────────── 月 (1-12)
│ │ │ │ ┌───────────── 星期几 (0-7, 0和7都是周日)
│ │ │ │ │
* * * * * command_to_execute

常用的便捷写法：

# 每天凌晨2点执行
0 2 * * * /opt/scripts/backup.sh

# 每小时的第15分钟执行
15 * * * * /opt/scripts/health-check.sh

# 每周一到周五早上9点执行
0 9 * * 1-5 /opt/scripts/workday-report.sh

# 每5分钟执行一次
*/5 * * * * /opt/scripts/monitor.sh

# 每月1号和15号凌晨3点执行
0 3 1,15 * * /opt/scripts/bi-monthly-task.sh

1.2 环境变量陷阱

Cron 的执行环境与你的 shell 不同，这是最常见的踩坑点：

# ❌ 错误：cron 中找不到 node/python 命令
0 2 * * * node /app/script.js

# ✅ 正确：使用绝对路径
0 2 * * * /usr/local/bin/node /app/script.js

# ✅ 更好的方式：在 crontab 顶部设置 PATH
PATH=/usr/local/bin:/usr/bin:/bin
0 2 * * * node /app/script.js

另一个常见问题是 cron 不加载 .bashrc，导致环境变量丢失：

# ✅ 通过 source 加载环境
0 2 * * * source /root/.bashrc && /opt/scripts/deploy.sh

# ✅ 或者在脚本中设置环境
#!/bin/bash
export PATH="/usr/local/bin:$PATH"
export NODE_ENV="production"
# ... 脚本逻辑

1.3 日志管理

Cron 的日志默认写入 /var/log/cron（CentOS）或 /var/log/syslog（Ubuntu）：

# 查看 cron 日志
grep CRON /var/log/syslog

# 或使用 journalctl（systemd 系统）
journalctl -u cron

# 在 crontab 中为任务单独记录日志
0 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

# 保留最近 7 天的日志（配合 logrotate）
0 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

1.4 Cron 的局限性

尽管 cron 很成熟，但存在一些固有问题：

没有依赖管理：任务之间无法声明依赖关系
缺少并发控制：如果上一次任务还没执行完，新的又启动了
日志碎片化：没有统一的查询和过滤机制
无资源限制：无法限制任务的 CPU/内存使用
重启后状态丢失：系统重启不会追踪错过执行的任务

二、Systemd Timer：现代替代方案

Systemd Timer 是 systemd 提供的定时任务方案，从 CentOS 7 / Ubuntu 15.04 开始支持。它解决了 cron 的许多痛点。

2.1 基本概念

Systemd Timer 需要两个文件：

Timer 文件（.timer）：定义触发规则
Service 文件（.service）：定义要执行的任务

这种分离设计使得配置更清晰，也更容易复用。

2.2 第一个 Timer 示例

假设我们要每小时执行一次健康检查：

创建 Service 文件 /etc/systemd/system/health-check.service：

[Unit]
Description=Server Health Check
After=network.target

[Service]
Type=oneshot
ExecStart=/opt/scripts/health-check.sh
User=root
StandardOutput=journal
StandardError=journal

创建 Timer 文件 /etc/systemd/system/health-check.timer：

[Unit]
Description=Run health check every hour

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

启用并启动：

# 重新加载配置
sudo systemctl daemon-reload

# 启用定时器（开机自启）
sudo systemctl enable health-check.timer

# 立即启动定时器
sudo systemctl start health-check.timer

# 查看定时器状态
sudo systemctl list-timers --all

2.3 OnCalendar 时间格式

Systemd Timer 的时间格式比 cron 更灵活：

# 固定间隔（cron 做不到的）
OnCalendar=*-*-* *:*:00    # 每分钟
OnCalendar=*-*-* *:00:00   # 每小时
OnCalendar=*-*-01 03:00:00  # 每月1号凌晨3点
OnCalendar=Mon *-*-* 09:00:00  # 每周一早上9点

# 带偏移的间隔
OnCalendar=Mon..Fri *-*-* 09:00:00  # 工作日早上9点
OnCalendar=*-*-01,15 03:00:00  # 每月1号和15号

# 相对间隔（使用 OnBootSec/OnUnitActiveSec）
OnBootSec=5min           # 开机后5分钟
OnUnitActiveSec=1hour    # 上次执行后1小时

2.4 持久化与错过执行

Persistent=true 是 systemd Timer 最实用的特性之一：

[Timer]
OnCalendar=daily
Persistent=true  # 如果错过的执行，会在系统启动后补上

这意味着如果服务器在凌晨2点宕机了，重启后 systemd 会自动补上错过的备份任务。Cron 做不到这一点。

2.5 并发控制

Systemd Timer 默认不会并发执行同一任务：

[Service]
Type=oneshot
# 如果上一次还没结束，新的执行会排队等待

# 或者配置超时
ExecStart=/opt/scripts/long-task.sh
TimeoutStartSec=3600  # 1小时超时

如果需要更精细的控制，可以使用 RemainAfterExit=yes 配合 ExecStop：

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/opt/scripts/start-task.sh
ExecStop=/opt/scripts/cancel-task.sh

三、实战对比：同一任务的两种实现

场景：每天凌晨2点备份 PostgreSQL 数据库

Cron 实现

# crontab -e
0 2 * * * /usr/bin/docker exec postgres pg_dump -U postgres mydb > /backup/db-$(date +\%Y\%m\%d).sql 2>> /var/log/db-backup.log

问题：

日志和输出混在一起
没有失败重试
没有并发保护
无法查看历史执行记录

Systemd Timer 实现

backup-db.service：

[Unit]
Description=PostgreSQL Daily Backup
After=docker.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh
User=root
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

backup-db.timer：

[Unit]
Description=Run database backup daily at 2 AM

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300  # 随机延迟0-5分钟，避免同时段所有备份同时跑

[Install]
WantedBy=timers.target

backup-db.sh：

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/backup"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=7

echo "[$(date)] Starting database backup..."

docker exec postgres pg_dump -U postgres mydb | \
  gzip > "${BACKUP_DIR}/db_${DATE}.sql.gz"

# 清理旧备份
find "${BACKUP_DIR}" -name "db_*.sql.gz" -mtime +${RETENTION_DAYS} -delete

echo "[$(date)] Backup completed: db_${DATE}.sql.gz"

优势：

# 查看最近执行记录
journalctl -u backup-db.service --since "7 days ago"

# 查看下一次执行时间
systemctl list-timers backup-db.timer

# 手动触发一次测试
systemctl start backup-db.service

四、选型决策树

在实际项目中，如何选择 Cron 还是 Systemd Timer？

特性	Cron	Systemd Timer
配置复杂度	简单（一行表达式）	中等（需要两个文件）
日志管理	分散（需自行重定向）	统一（journalctl）
错过执行补执行	❌ 不支持	✅ Persistent=true
并发保护	❌ 无（需自行实现）	✅ 默认禁止并发
资源限制	❌ 无	✅ 可用 cgroup 限制
依赖声明	❌ 无	✅ After/Wants
历史记录	需自建	✅ 内置
适用系统	所有 Linux	仅 systemd 系统
适合场景	简单脚本、一次性任务	生产环境、需要可靠性

推荐策略：

快速脚本/CI/CD：用 Cron，配置快，够用
生产环境关键任务：用 Systemd Timer，可靠性和可观测性更好
容器环境：如果容器内没有 systemd，用 Cron；宿主机用 Timer 管理容器
旧系统：CentOS 6 等不支持 systemd 的系统只能用 Cron

五、较完整的建议

5.1 Cron 建议

# 1. 所有脚本使用绝对路径
0 2 * * * /usr/local/bin/python3 /opt/scripts/backup.py

# 2. 设置 MAILTO 接收错误通知
MAILTO="admin@example.com"
0 2 * * * /opt/scripts/backup.sh

# 3. 锁文件防止并发
0 * * * * flock -n /tmp/backup.lock /opt/scripts/backup.sh

# 4. 统一日志目录
0 2 * * * /opt/scripts/backup.sh >> /var/log/tasks/backup.log 2>&1

# 5. 禁止用户交互
# crontab 中不要用 sudo -i 或 source 等会启动 shell 的命令

5.2 Systemd Timer 建议

# 1. 使用 systemd-analyze 查看配置是否正确
systemd-analyze verify /etc/systemd/system/backup-db.timer

# 2. 用 RandomizedDelaySec 避免惊群效应
[Timer]
OnCalendar=daily
RandomizedDelaySec=1800  # 最多延迟30分钟

# 3. 设置合理的资源限制
[Service]
CPUQuota=50%
MemoryMax=512M
TimeoutStartSec=3600

# 4. 使用 systemd-cat 统一日志标签
ExecStart=/bin/bash -c 'echo "Starting backup" | systemd-cat -t backup'

# 5. 创建 timer 的健康检查（meta-monitoring）
# 另一个 timer 定期检查主 timer 是否正常
[Timer]
OnCalendar=hourly
ExecCondition=/usr/bin/systemctl is-active backup-db.timer

5.3 监控与告警

无论选择哪种方案，都需要监控定时任务是否正常执行：

#!/bin/bash
# monitor-task.sh - 监控定时任务执行状态

LAST_RUN=$(systemctl show backup-db.service --property=ExecMainExitTimestamp --value)
NOW=$(date +%s)
LAST_EPOCH=$(date -d "$LAST_RUN" +%s 2>/dev/null || echo 0)
DIFF=$((NOW - LAST_EPOCH))

# 如果超过 25 小时没执行（允许1小时误差），发送告警
if [ $DIFF -gt 90000 ]; then
    echo "WARNING: backup-db hasn't run for $((DIFF/3600)) hours!"
    # 发送告警通知...
fi

六、迁移指南：从 Cron 迁移到 Systemd Timer

如果你已有大量 cron 任务，可以分步迁移：

# 1. 列出所有 cron 任务
crontab -l

# 2. 按重要性排序，优先迁移关键任务

# 3. 为每个任务创建 .service + .timer 文件
# 使用以下模板批量生成：

#!/bin/bash
# migrate-cron-to-timer.sh
TASK_NAME=$1
EXEC_CMD=$2
CRON_SCHEDULE=$3

# 生成 service 文件
cat > /etc/systemd/system/${TASK_NAME}.service << EOF
[Unit]
Description=${TASK_NAME} (migrated from cron)

[Service]
Type=oneshot
ExecStart=${EXEC_CMD}
StandardOutput=journal
StandardError=journal
EOF

# 生成 timer 文件（需要手动调整 OnCalendar）
cat > /etc/systemd/system/${TASK_NAME}.timer << EOF
[Unit]
Description=Timer for ${TASK_NAME}

[Timer]
OnCalendar=${CRON_SCHEDULE}
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable ${TASK_NAME}.timer
echo "Created timer for ${TASK_NAME}"

总结

Cron 和 Systemd Timer 各有优劣。Cron 简单直接，适合快速搭建和简单场景；Systemd Timer 功能强大，适合需要可靠性、可观测性和精细控制的生产环境。

建议的演进路径：先用 Cron 验证需求 → 稳定后迁移到 Systemd Timer。大多数 Linux 发行版默认同时支持两者，完全可以共存。

对于现代 Linux 运维来说，掌握 Systemd Timer 已经不是"加分项"而是"必备技能"。它与 systemd 生态的深度集成（日志、资源控制、依赖管理）让它成为生产环境定时任务的最佳选择。

Linux 定时任务：Cron 与 systemd Timer 的选择