crontab 定时任务总跑不起来？先查这五处

云服务器上跑定时任务，crontab 是最顺手的工具，可它有个毛病：任务没跑起来时一声不吭。脚本在终端里明明能跑，放进 crontab 就没动静，这种情况我遇到过好几次，原因基本都落在下面五处，逐个排查很快就能定位。

第一处是时间写法。crontab 五个字段依次是分、时、日、月、周，很多人把“每天凌晨三点”写成 3 0 * * *，其实是 0 3 * * *。星期字段里 0 和 7 都代表周日，写错了任务会在意料之外的日子跑。改完先用 crontab -l 对一遍，再等一个周期验证。

第二处是环境变量。crontab 执行时的环境非常干净，PATH 里只有 /usr/bin:/bin，自己装在 /usr/local/bin 下的命令、conda 环境、nvm 装的 node，定时任务里都找不到。稳妥的做法是在脚本开头写死绝对路径，或者在 crontab 文件顶部先声明 PATH。凡是“手动能跑、定时跑不了”，先怀疑这一处。

第三处是工作目录。定时任务的默认工作目录是用户家目录，脚本里写相对路径 ./data、…/backup 都会跑偏。脚本里凡是读写文件的地方，一律用绝对路径，或者在脚本开头 cd 到固定目录再干活。

第四处是输出去向。crontab 默认把任务的输出发给本机邮件，没配邮件服务就等于直接丢了，查问题无从下手。建议每条任务都重定向输出，比如 >> /var/log/backup.log 2>&1，配上日期轮转，任务跑没跑、报错是什么，看日志一眼就清楚。

第五处是服务本身。改完 crontab 不用重启 cron 服务，它每分钟会自动重载，但要确认 cron 服务在运行：systemctl status cron 看一眼。另外编辑时用 crontab -e，别直接改 /etc/crontab 以外的系统文件，权限和归属一旦乱了，任务会被悄悄跳过。

最后还有一条习惯：重要任务别只依赖“跑没跑”的猜测。备份类任务跑完后写一行带时间戳的完成记录到日志，清理类任务记录删了多少文件。日志就是定时任务的眼睛，没有它，排障全靠运气。

把这五处养成检查清单，crontab 基本就不会再半夜掉链子。