Linux crontab 定时任务不运行排查：从 PATH 到工作目录和日志

Linux 上很多备份、统计、同步任务都会放进 crontab。问题也很典型：手动运行脚本一切正常，写进定时任务后却没有结果。更麻烦的是，屏幕上没有报错，业务侧只看到数据没有更新。

这篇文章从一个“每天凌晨统计脚本没有产出文件”的现场出发，按触发记录、运行环境、工作目录、权限和日志逐步排查。目标不是背 crontab 语法，而是形成一套能在服务器上快速复查的定位流程。

问题现场：手动能跑，定时没有结果

假设我们有一个统计任务，手动运行能生成报表：

cd /opt/report
/usr/bin/python3 job.py

但放进 crontab 后，第二天发现文件没有更新：

0 2 * * * python3 /opt/report/job.py

这时不要急着改时间表达式。先把问题拆成两个方向：cron 有没有按时触发？触发后脚本有没有在正确环境里跑完？这两个方向对应的证据不同，混在一起查会很慢。

初步判断：任务没触发还是脚本没跑完

我们先建立一条排查路径。定时任务失败不一定是时间写错，也可能是没有加载登录 shell 的环境变量、默认工作目录不是项目目录、命令路径不完整，或者脚本输出没有被记录下来。

判断顺序建议固定下来：

• 先确认 crontab 里确实有这条任务。
• 再确认 cron 进程在目标时间点有触发记录。
• 然后检查脚本自己的日志和退出状态。
• 最后看路径、工作目录、权限和并发问题。

动手验证：先看 cron 记录和脚本日志

第一步看当前用户的定时任务列表：

crontab -l

如果任务由其他用户维护，要切到对应用户检查。很多“任务没跑”的问题，其实是写到了 root 的 crontab，但期待普通用户目录里产生文件。

第二步看 cron 触发记录。不同发行版日志位置不同，可以按实际环境选择：

grep CRON /var/log/syslog | tail -20
grep CROND /var/log/cron | tail -20
journalctl -u cron --since "2 hours ago"
journalctl -u crond --since "2 hours ago"

如果能看到类似记录，说明 cron 至少尝试启动过命令：

Jun 20 02:00:01 server CRON[1248]: (app) CMD (python3 /opt/report/job.py)

第三步，给任务补上输出日志。没有日志时，脚本失败只会安静地失败，排查会变成猜。

0 2 * * * /usr/bin/python3 /opt/report/job.py >> /var/log/report-job.log 2>&1

再次等待或临时改成每分钟触发后，查看日志：

tail -100 /var/log/report-job.log

如果看到 command not found、No such file、Permission denied 这类信息，方向就很明确了。

定位原因：PATH、工作目录和权限最常见

crontab 的运行环境比你手动登录后更“干净”。手动能跑，不代表定时任务能找到同样的命令、配置和相对路径。

原因 1：PATH 不包含命令所在目录

比如手动输入 python3 可以找到，但 cron 环境里找不到。解决方式是使用完整路径，先查命令位置：

which python3
which bash
which flock

然后在 crontab 里写绝对路径，或者显式设置 PATH。

原因 2：默认工作目录不是项目目录

脚本里如果读取 ./config.yml、./data/input.csv 这类相对路径，手动运行时没问题，cron 触发时就可能找不到。推荐在命令前加 cd：

0 2 * * * cd /opt/report && /usr/bin/python3 job.py >> /var/log/report-job.log 2>&1

原因 3：脚本或目录权限不对

定时任务以哪个用户运行，就只能访问这个用户有权限的目录和文件。检查脚本、输出目录和日志文件：

ls -ld /opt/report
ls -l /opt/report/job.py
ls -ld /var/log

如果任务需要写入业务目录，建议让目录归属于任务用户，或者把输出路径放到明确授权的目录里。不要依赖手动运行时临时拥有的权限。

修复方案：写清绝对路径、环境和日志

现在可以把任务改成更稳的版本：顶部设置基础环境，命令使用绝对路径，进入项目目录，再把标准输出和错误输出都写入日志。

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

0 2 * * * cd /opt/report && /usr/bin/python3 job.py >> /var/log/report-job.log 2>&1

如果任务可能跑很久，下一次触发时还没结束，可以加 flock 防止并发叠加：

*/5 * * * * /usr/bin/flock -n /tmp/report-job.lock /bin/bash -lc 'cd /opt/report && /usr/bin/python3 job.py' >> /var/log/report-job.log 2>&1

这里的重点是三件事：任务入口清晰、运行环境可复现、失败原因有日志可查。这样下次失败时不用靠猜。

验证结果：立刻触发一次并观察输出

修复后不要等到第二天。可以临时把时间改成每分钟一次，或者直接用同一个用户手动运行 crontab 里的完整命令：

cd /opt/report && /usr/bin/python3 job.py >> /var/log/report-job.log 2>&1
echo $?
tail -50 /var/log/report-job.log

观察三项结果：

• echo $? 返回 0，说明命令正常结束。
• 日志里有开始、结束和关键统计数量。
• 目标文件或业务数据在预期位置更新。

最后把临时的一分钟触发改回正式时间，避免测试配置留在线上。

总结清单：下次排查按这 7 步走

1. 用 crontab -l 确认任务写在正确用户下。
2. 用 cron 日志确认目标时间点是否触发。
3. 给任务追加 >> log 2>&1，先拿到错误信息。
4. 命令尽量写绝对路径，不依赖登录后的 PATH。
5. 涉及相对路径时，先 cd 到项目目录。
6. 检查任务用户对脚本、配置、输出目录和日志文件的权限。
7. 长任务加 flock，避免上一次没结束又启动下一次。

crontab 问题看起来零散，本质上是在确认“谁、什么时候、在哪个目录、用什么环境、把结果写到哪里”。把这几个条件写清楚，定时任务就会从不可见的后台动作变成可验证的工程流程。