crontab 定时任务不生效：从服务状态到环境变量的排查顺序

定时任务到了时间没跑，是最让人挠头的故障之一：手动跑脚本好好的，放进 crontab 就没动静。先按顺序排查。

一、先确认 cron 服务在运行

先看 cron 服务本身。Debian、Ubuntu 上叫 cron，RHEL、CentOS 上叫 crond：

systemctl status cron

没在运行就启动并设开机自启：

systemctl enable --now cron

状态为 active (running) 才能往下查。

二、查执行记录：任务到底跑没跑

再确认任务有没有被触发：RHEL 系看 /var/log/cron，systemd 发行版查：

journalctl -u cron --since "1 hour ago"

记录里出现 CMD (...) 说明到点触发过；没有记录，问题在服务或时间表达式上；有记录但没效果，问题在脚本或环境里。

三、分清 crontab -l 与 /etc/crontab

crontab -l 是当前用户的个人定时任务，crontab -e 编辑的也是它；/etc/crontab 是系统级任务表，格式多一列“以哪个用户身份运行”：

分 时 日 月 周 用户 命令

例如每天凌晨两点以 root 身份跑备份：

0 2 * * * root /opt/backup.sh

个人 crontab 没有“用户”这一列，照抄会错。改完不用重启，cron 每分钟重新读表，保存后立即生效。

四、脚本本身：绝对路径与可执行权限

触发了但没效果，先看脚本：命令、脚本路径、脚本里引用的文件一律用绝对路径，脚本要加可执行权限：

chmod +x /opt/backup.sh

第一行写全解释器路径，如 #!/bin/bash；先在终端手动跑一遍确认没问题，再放进 crontab。

五、最常见的坑：cron 的环境变量和交互终端不一样

这是最常见的坑。cron 的任务环境非常简陋：PATH 只有 /usr/bin:/bin 左右，/usr/local/bin 下的工具可能找不到；SHELL、HOME、工作目录都和登录终端不一样，相对路径和 ~ 都不可靠。终端里能跑的命令放到 cron 里报 command not found，十有八九是 PATH 的问题。解决办法：在 crontab 开头定义 PATH 和 SHELL，或在脚本里写死绝对路径、开头先 cd 到固定工作目录；需要环境变量时在脚本内显式 export。

六、重定向输出留证据

cron 执行结果默认发邮件给任务属主，没配邮件就等于丢了。把标准输出和标准错误重定向到日志文件：

0 2 * * * /opt/backup.sh >> /var/log/backup.log 2>&1

以后排查先看这个日志：报“找不到命令”看 PATH，报“找不到文件”看路径和工作目录，报“权限拒绝”看权限和属主。时间表达式拿不准时，先用 * * * * * 验证链路，再改回真正的时间。

七、一个完整的排查顺序

1. systemctl status cron，确认服务在运行；
2. crontab -l 确认表和时间表达式无误；
3. 查 /var/log/cron 或 journalctl -u cron，确认到点有没有触发；
4. 看重定向日志逐项修正，每次只改一处，等下一个周期验证。

总结：按“服务状态—执行记录—任务表—脚本与权限—环境变量—重定向日志”的顺序排查，多数故障都能快速定位。