crontab任务不执行90%是环境或路径问题：先确认cron服务运行状态，再检查path、shell语法兼容性及日志重定向。

crontab 能跑起来，但任务不执行，90% 是环境或路径问题，不是语法写错了。

crontab -e 编辑后任务不触发？先看 cron 服务有没有在跑

crontab 文件本身只是配置，真正干活的是 crond（CentOS/RHEL）或 cron（Debian/Ubuntu）服务。配置再对，服务停了就等于没写。

• 查状态：systemctl status cron（Debian/Ubuntu）或 systemctl status crond（CentOS/RHEL）
• 如果显示 inactive (dead)，运行：sudo systemctl start cron 并加开机自启：sudo systemctl enable cron
• 注意：改完 /etc/crontab 或 /etc/cron.d/ 下的文件，不需要重启服务；但改用户级 crontab -e 后，也无需重启——crond 每分钟自动检查，通常 30 秒内生效

为什么脚本在终端能跑，放进 crontab 就报 command not found？

crond 启动时用的是 minimal shell（/bin/sh），不加载你的 ~/.bashrc、/etc/profile，PATH 很短，常见命令如 python3、node、mysqldump 都可能找不到。

• 用 which python3 或 command -v mysqldump 查绝对路径，写进 crontab，例如：/usr/bin/python3 /home/user/script.py
• 或者在 crontab 文件顶部显式声明 PATH：PATH=/usr/local/bin:/usr/bin:/bin
• 别在命令里用 bash 特有语法（比如 [[ ]]、数组、source ~/.bashrc），/bin/sh 不认

日志没输出、不知道任务到底跑没跑？必须重定向

crontab 默认把 stdout 和 stderr 发邮件给当前用户（多数系统没配本地邮件服务，结果就是“静默失败”）。

• 加日志重定向是最简单有效的排查手段：0 2 * * * /backup.sh >> /var/log/backup.log 2>&1
• 想确认 crond 是否调用了你的任务，可在脚本第一行加：echo "$(date): started" >> /tmp/myjob.debug
• 系统级日志可查：grep CRON /var/log/syslog（Debian/Ubuntu）或 journalctl -u cron -n 50（systemd 系统）

测试新任务别等一小时：用近时间 + 简单 echo 快速验证

刚写完一行，别设成 0 3 * * * 等到凌晨三点——浪费时间还容易误判。

• 假设现在是 11:57，设成 58 11 * * *，两分钟后就能看到是否写入日志或生成文件
• 测试命令优先用 echo 或 touch：58 11 * * * touch /tmp/crontab_test_$(date +\%s)
• 注意：时间字段里的 % 是特殊字符，需转义为 \%，否则 crond 会截断命令

最容易被忽略的其实是环境隔离——你写的脚本在终端里跑得欢，不代表它在 crond 的 /bin/sh 里也能活下来。PATH、shell 语法、输出通道，三者缺一不可。调试时别猜，先看日志，再看系统 cron 日志，最后比对 PATH。