每个人都可以，
拥有SSL证书

刚用 crontab 那阵子，我经常遇到一种情况：明明手动跑脚本好好的，一放到定时任务里就没动静。一开始会怀疑是不是 cron 服务挂了，查一遍发现服务正常，日志里就躺着一个 command not found，或者干脆什么都没有。

后来踩多了才慢慢搞清楚，问题基本都出在几个固定的地方。

先说时间字段格式。 crontab 里那五个星号，顺序是 分钟、小时、日、月、星期。分钟的范围是 0-59，有人顺手写了个 60，比如：

60 * * * * echo "test"

这种情况 cron 日志里就会报 bad hour 或者 bad command，任务不会执行。把它改成 0-59 以内的值，比如 30 就行。星期字段也容易写岔，0 和 7 都代表周日，但有些系统只认 0，不确定的时候用数字 0 比较稳。五个字段一个都不能少，缺了星期字段也会直接报错。

另一个坑是命令没写绝对路径。在 shell 里直接敲 python script.py 没问题，是因为 shell 的环境变量里有 PATH，知道去哪里找 python。cron 的运行环境极其干净，PATH 里通常只有 /usr/bin 和 /bin，根本找不到你装在 /usr/local/bin 下的程序，也找不到你自定义脚本里用的那些工具。

所以日志里经常就一个 command not found。解决方法很简单，用 which python 拿到完整路径，比如 /usr/bin/python，然后在 crontab 里写成：

• • • • • /usr/bin/python /home/user/script.py

脚本里面如果调了其他命令，最好也全部写绝对路径，或者在脚本开头重新设置一遍 PATH。

百分号 % 这个字符在 crontab 里有特殊含义，不转义会被当成换行符，导致后面的内容变成命令的标准输入。想输出带日期格式的字符串，比如 date +%F，不加处理的话，cron 会把 %F 后面的东西全搞乱。处理方式有两种，要么用反斜杠转义成 +%F，要么给格式字符串加单引号写成 +'%F'，两者都可以。我习惯直接在格式外面套一对单引号，少敲一个反斜杠。

环境变量问题是和绝对路径连着一起出现的。除了在命令前面把路径写全，另一个办法是直接在 crontab 文件顶部定义一个 PATH。像这样：

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

后面的所有任务就都能认这些路径了。

如果你的脚本依赖 JAVA_HOME 之类的变量，同样可以在这里 export，或者在脚本里显式 export，看个人习惯。我一般把环境变量写在脚本里，这样换机器的时候不太容易忘。

顺便提一句，编辑 /etc/crontab 这类系统级的 crontab 文件，记得用 sudo，不然保存的时候就会报权限不够。

定时任务跑不起来，有时候只是你根本没成功把配置写进去。

还有一个很容易被忽略的点：日志。任务跑失败了，光盯着 crontab 猜是没用的，得让它把错误信息吐出来。在命令后面加重定向：

• • • • • /path/to/command >> /tmp/cron.log 2>&1

标准输出和标准错误都丢进一个文件，出问题了一看便知。临时调试的时候我会专门开一个这样的条目，盯着那个 log 看几次执行结果。

一套比较完整的 crontab 配置长这样：

PATH=/usr/bin:/bin

30 8 * * * /home/user/backup.sh

*/5 * * * * /usr/bin/date +%F_%T >> /tmp/time.log

每天八点半跑备份，每五分钟记录一次时间，百分号也处理了。

如果改了半天还是不行，可以把当前的 crontab 备份一份后清掉，再一条一条加回来测试。备份用 crontab -l > backup.cron，清空用 crontab -r。

一条任务能跑了，再加下一条，这样至少能确定是哪一行搞出的问题。

上面这些基本覆盖了配置 crontab 时最容易出错的几个环节。时间字段写对，命令用绝对路径，% 记得转义，环境变量补全，输出重定向打开，出问题的概率就非常小了。

遇到任务不执行的时候，顺着这个思路查一圈日志，一般都能很快定位到。