systemd 定时器替代 crontab：写法与取舍

发布时间:2026-07-02 10:52

## 两个选项对比 crontab 是传统的定时任务入口，一行表达式加一条命令，简单直接，几乎所有类 Unix 系统都支持。systemd 定时器则由一对文件组成：timer 单元定义触发时间，同名 service 单元定义要执行的动作，两者必须成对出现，缺一不可。 timer 的核心字段是 OnCalendar，写法如三点半执行就用日历表达式表达，也可以用 OnUnitActiveSec 按间隔触发。补执行能力是它的一大优势，Persistent 设为 true 后，错过的触发会在下次开机补跑一次，crontab 关机期间的任务则直接丢失。 ``` [Unit] Description=Daily backup timer [Timer] OnCalendar=*-*-* 03:30:00 Persistent=true RandomizedDelaySec=300 [Install] WantedBy=timers.target ``` ## 各自适用面 定时器的执行日志自动进入 journal，用 journalctl -u 服务名即可翻查，配合 sar 的系统数据容易对时间线；它还能声明依赖，例如等网络就绪、等数据库服务起来再执行，这在 crontab 里要自己写判断。crontab 的优势是零学习成本、跨机器通用、编辑即生效，一个一行的小任务用它更快。 ## 选择建议 混合使用是务实做法：普通的小任务继续留在 crontab，重要的、需要补执行、有依赖关系、要看历史日志的任务逐步迁到定时器。顺云云服务器上如果定时任务分布在多台机器，统一用定时器管理后，排查漏跑问题时查 journal 比翻邮件与日志文件省事得多。迁移时两类并存要避免同一任务双跑，先删旧的再加新的。 迁移还有一个容易低估的差异：环境变量。crontab 的任务运行在精简环境里，PATH 与登录 shell 不同，脚本里用到的命令可能找不到；定时器的 service 单元环境同样干净，但可以在 unit 里显式声明环境变量，把依赖写清楚，排障时一眼可见。从这一点看，定时器把隐性的环境问题变成了显性的配置项。 实践中推荐的迁移顺序是先难后易：带补跑需求的、跨机器需要统一管理的任务先迁，简单的保留原处。每迁一个任务，在 journal 里核对一次实际执行时间与耗时，确认随机延迟的抖动幅度在预期内。全部迁完再观察一个完整周期，清单逐项销号，迁移才算结束。