Cron
经典Unix任务调度器
Systemd Timer
现代服务型调度器
Cron和Systemd Timer调度器的全面比较。了解何时使用每个调度器、它们的功能、优缺点，以及如何在它们之间迁移。
Quick Comparison
| Feature | ⏰ Cron | ⚙️ Systemd Timer |
|---|---|---|
| 调度方式 | 仅基于时间 | 基于时间或事件 |
| 粒度 | 分钟 | 微秒 |
| 依赖关系 | 无 | 完全支持 |
| 日志记录 | 基本邮件/日志 | journald集成 |
| 每个用户作业 | 是 | 是 |
| 单调定时器 | 否 | 是 |
| 资源跟踪 | 否 | 是 (cgroups) |
| 平台覆盖 | 通用 | 仅systemd |
| 学习曲线 | 简单 | 中等 |
| 容器友好 | 优秀 | 差 |
核心功能
调度精度
Cron: 分钟级别
Systemd Timer: 微秒级别
💡 Why: Systemd定时器支持更细粒度的调度，具有微秒精度，而cron仅支持分钟级别的粒度。
实时调度
Cron: ✅ 完全支持
Systemd Timer: ✅ 完全支持
💡 Why: 两者都支持传统的基于时间的调度（例如"每天凌晨3点"）。
单调定时器
Cron: ❌ 不支持
Systemd Timer: ✅ 完全支持
💡 Why: Systemd支持基于自启动或其他事件经过时间的定时器，而cron无法做到这一点。
事件触发
Cron: ❌ 无
Systemd Timer: ✅ 多种事件
💡 Why: Systemd可以在硬件事件、路径更改和其他系统事件上触发。
配置与管理
配置格式
Cron: Crontab（简单）
Systemd Timer: INI风格单元
💡 Why: Cron使用简单且众所周知的crontab格式。Systemd使用更复杂的单元文件。
每个用户的调度
Cron: ✅ 支持
Systemd Timer: ✅ 支持
💡 Why: 两者都支持每个用户的调度（用户crontabs vs systemd用户单元）。
环境变量
Cron: 有限
Systemd Timer: 完全支持
💡 Why: Systemd通过服务文件提供更好的环境变量管理。
依赖管理
Cron: ❌ 无
Systemd Timer: ✅ 完全支持
💡 Why: Systemd定时器可以依赖于服务、套接字、目标和其他单元。
日志与监控
内置日志记录
Cron: 邮件/日志
Systemd Timer: journald
💡 Why: Systemd与journald紧密集成，提供可搜索的结构化日志。
作业历史
Cron: 有限
Systemd Timer: ✅ 已跟踪
💡 Why: Systemd保留定时器触发和服务结果的详细历史记录。
资源监控
Cron: ❌ 无
Systemd Timer: ✅ cgroups
💡 Why: Systemd通过cgroups跟踪每个服务的资源使用情况。
失败处理
Cron: 仅邮件
Systemd Timer: 多个选项
💡 Why: Systemd支持失败触发器、重启策略和基于依赖关系的反应。
性能与资源
内存使用
Cron: ~1-2 MB
Systemd Timer: ~5-10 MB
💡 Why: Cron守护进程使用的内存最少。Systemd已经在运行，因此定时器增加的开销可忽略不计。
启动时间
Cron: 快速
Systemd Timer: 即时
💡 Why: Systemd是init的一部分，在启动时已经在运行。
可扩展性
Cron: 良好
Systemd Timer: 优秀
💡 Why: Systemd通过现代进程管理更高效地处理数千个单元。
系统集成
Cron: 独立
Systemd Timer: 集成
💡 Why: Systemd定时器是基于systemd的系统原生的。
平台与兼容性
Linux支持
Cron: ✅ 通用
Systemd Timer: 仅systemd
💡 Why: Cron在所有Linux系统上都可用。Systemd定时器仅在基于systemd的发行版上可用。
Unix/BSD支持
Cron: ✅ 是
Systemd Timer: ❌ 否
💡 Why: Cron几乎在所有类Unix系统上都可用。
macOS支持
Cron: ✅ launchd/cron
Systemd Timer: ❌ 否
💡 Why: macOS使用launchd（不是systemd），但cron可用。
容器支持
Cron: ✅ 简单
Systemd Timer: 复杂
💡 Why: Cron在最小容器中可用。Systemd需要完整的systemd init。
Practical Examples
简单每日备份
Cron
# 每天凌晨2点运行备份
0 2 * * * /root/backup.sh
对于这个基本任务，Cron更简单。Systemd需要两个文件（定时器+服务），但提供跨重新启动的持久性。
启动后15分钟运行
Cron
# 不容易支持
# 需要使用@reboot和sleep
Systemd原生支持启动延迟执行。Cron需要复杂的变通方法。
网络启动时运行
Cron
# 不支持
Systemd可以等待特定的系统状态。Cron没有依赖感知。
Migration Guide
Cron → Systemd Timer
- → 创建.timer和.service文件（cron条目=定时器+服务组合）
- → 使用OnCalendar进行基于时间的调度（转换cron表达式）
- → 使用Persistent=true运行在停机期间错过的作业
- → 将环境变量从crontab移动到[Service] Environment=
- → 将邮件输出替换为journald日志记录
- → 将用户crontabs转换为systemd用户单元（~/.config/systemd/user/）
- → 使用systemctl list-timers查看所有定时器（类似于crontab -l）
Cron → Systemd Timer
- → 失去依赖管理 - 脚本必须处理依赖
- → 将OnCalendar转换为cron表达式（分钟 小时 日期 月份 星期）
- → 将单调定时器（OnBootSec）替换为@reboot和sleep
- → 删除基于事件的触发器（cron仅支持时间）
- → 环境变量放在crontab或脚本中
- → 必须手动处理日志记录（syslog、自定义文件）
- → 没有内置持久性 - 在脚本中手动跟踪上次运行
Frequently Asked Questions
对于新的Linux服务器应该选择哪个？ ▼
Cron和systemd定时器可以共存吗？ ▼
如何像crontab -l一样查看所有计划的任务？ ▼
Systemd定时器在Docker容器中可以工作吗？ ▼
Cron是否被弃用？ ▼
Systemd定时器能像cron一样在失败时发送电子邮件吗？ ▼
哪一个使用的系统资源更少？ ▼
如何安排作业每10秒运行一次？ ▼
Verdict: 无 - 根据需求选择
Cron和systemd定时器都是强大的作业调度器，服务于不同的需求。**Cron仍然是所有类Unix系统简单、可移植调度的通用选择**。**Systemd定时器在现代Linux发行版上表现出色**，需要复杂的依赖关系、事件触发器和集成日志记录。
Recommendation
对于简单的周期性任务、跨平台兼容性、旧系统和容器，使用**cron**。对于现代Linux服务器、服务编排、事件驱动调度以及需要与系统服务紧密集成的情况，使用**systemd定时器**。