crontab 是 Linux 最常用的定时任务工具，很多人写完任务发现“到点就是不跑”，却不知道问题出在哪。crontab 不执行几乎都可以归为五类：时间格式错、服务没起、环境变量缺、权限或路径错、日志被吞。本文按排查顺序给出可直接照做的命令。

一、先确认 crond 服务在运行

systemctl status crond

如果是 inactive，先启动并设开机自启：

systemctl start crond
systemctl enable crond

部分发行版服务名是 cron（Ubuntu/Debian）：

systemctl status cron

二、查看当前用户的定时任务

crontab -l

查看系统级任务：

cat /etc/crontab
ls /etc/cron.d/

注意：crontab -l 看的是当前用户；root 的任务要切到 root 下看，别拿普通用户去核对。

三、时间格式最容易写错

crontab 分五段：分 时 日 月 周，例如每天凌晨 2 点执行：

0 2 * * * /root/backup.sh

常见错误：

• 写成 5 段以外的字段数，直接不执行。
• 分钟位留空或写成 表示每分钟，别和“每天”混淆。
• 想每 5 分钟写 /5，而不是 /5。

四、环境变量与绝对路径

task 运行在极简环境里，PATH 只有 /usr/bin:/bin，脚本里直接写命令名往往找不到。必须用绝对路径：

# 错误：依赖 PATH
* * * * * python3 /root/run.py

# 正确：命令也写绝对路径
* * * * * /usr/bin/python3 /root/run.py

脚本开头显式声明环境：

#!/bin/bash
PATH=/usr/local/sbin:/usr/bin:/bin
export PATH

五、查看 cron 日志定位

# CentOS7
tail -f /var/log/cron

# Ubuntu/Debian
tail -f /var/log/syslog | grep CRON

到点时日志里有没有出现这条任务，是判断“到底有没有被调度”的关键。也可以在任务末尾把输出重定向到文件：

0 2 * * * /root/backup.sh >> /root/backup.log 2>&1

2>&1 把错误输出也收进来，否则报错会被直接吞掉，表面看像没执行。

六、权限与其他拦路虎

1. 脚本没有可执行权限：chmod +x /root/backup.sh。
2. 脚本本身报错，但没重定向，看不到。
3. SELinux 或防火墙拦截脚本里的网络操作。
4. 系统时区不对，任务按 UTC 跑，和你以为的北京时间差 8 小时：timedatectl 查看。
5. /etc/cron.deny、/etc/cron.allow 把用户禁用了。

常见坑

1. 只在命令行手动测试成功，不代表 cron 环境能跑，重点是缺环境变量和绝对路径。
2. 改完任务没保存或改错用户，crontab -l 核对不到等于没写。
3. 忽略 2>&1，报错被吞，以为“没反应”。
4. 时区错位，任务在你睡着时的另一时刻执行。
5. 脚本换行要用 LF，Windows 存成 CRLF 会导致执行异常。

总结

排查顺序：crond 是否运行 → crontab -l 核对格式 → 命令与脚本改用绝对路径 → 加 2>&1 重定向看日志 → 检查权限、时区、SELinux。绝大多数“不执行”都卡在环境变量和绝对路径这一步。

遇到问题加QQ23979811 协助处理