crontab 定时任务没跑，我先查的三个地方

定时任务最怕的不是报错，而是悄悄没跑。

昨天加的备份脚本，今天一看，备份文件没生成。脚本本身在终端里手动跑是好的，问题就出在 cron 这边。后来我养成了一个习惯：定时任务没跑，先按下面三处过一遍，大多数时候不用改脚本就能找到原因。

一、先确认任务有没有进 cron

先看这条任务在不在、cron 服务在不在：

crontab -l
systemctl status cron

两点容易忽略：一是 crontab -l 只看得到当前用户的任务，root 的任务要用 sudo crontab -l 单独看；二是机器重启后 cron 服务没起来，也会造成任务集体没跑。

二、去日志里对时间，看它到底跑没跑

cron 每次执行都会记一笔，拿时间戳和命令对一下，就知道它动没动：

grep CRON /var/log/syslog
journalctl -u cron --since "today"

如果日志里有执行记录，但预期的结果文件没生成，说明任务跑了，但命令本身在 cron 环境里出了问题；如果日志里连记录都没有，问题还在前面那一步。

三、最后查环境变量和路径

cron 的环境很干净，PATH 一般只有 /usr/bin:/bin，很多在终端能用的命令，到了 cron 里就找不到了。相对路径和自定义命令最容易踩坑；另外，输出不写重定向，报错就直接丢了。

我现在的写法是：命令全部写绝对路径，输出重定向到一个日志文件：

0 3 * * * /usr/bin/python3 /home/yd/backup.py >> /var/log/backup.log 2>&1

改完之后先在终端手动跑一遍同一条命令，再等一次定时触发，第二天早上看一眼日志文件，两分钟就能确认。

任务查 crontab -l、执行查日志、跑不起来查环境和路径。定时任务最怕的不是没跑，而是不知道它没跑，把输出落到日志里，问题就藏不住了。