Linux定时任务不执行，多数情况不是crontab本身坏了，而是环境、权限、路径或语法细节出了问题。排查要从执行环境差异入手，而不是一上来就重写脚本。
确认crond服务是否运行
crontab依赖后台服务 crond（CentOS/RHEL）或 cron（Ubuntu/Debian）。服务没启，所有任务都静默失效。
- 检查状态：
systemctl status crond（或cron） - 若未运行，启动并设开机自启：
systemctl enable --now crond - 注意：部分容器环境默认不启用crond，需手动配置
验证crontab语法与用户上下文
crontab -e 编辑的规则属于当前用户，但实际执行时不会加载你的交互式shell环境（如~/.bashrc），PATH、HOME、Shell变量都不同。
- 用
crontab -l确认规则已保存，且格式正确（5个时间字段+命令） - 避免使用
~表示家目录，改用绝对路径，例如/home/user/script.sh - 在命令前显式指定shell和环境，例如：
0 2 * * * /bin/bash /home/user/backup.sh > /tmp/backup.log 2>&1
检查日志与执行痕迹
crond 默认记录到系统日志，但具体位置因发行版而异，且需确保rsyslog/syslog服务正常。
- 查看cron日志：
• CentOS/RHEL：journalctl -u crond -n 50 --no-pager或grep CRON /var/log/cron
• Ubuntu/Debian：journalctl -u cron -n 50 --no-pager或grep CRON /var/log/syslog - 日志中出现
(user) CMD (command)表示已触发；若无记录，说明未到达调度时间或规则未加载 - 临时加一行测试：
* * * * * date >> /tmp/crontest.log 2>&1，等1分钟看文件是否更新
权限、路径与脚本自身问题
即使crond调起了命令，脚本也可能因权限不足、缺少依赖或相对路径失败而“看似没执行”。
- 确保脚本有执行权限：
chmod +x /path/to/script.sh - 脚本内避免使用别名、未声明的函数，所有命令尽量用绝对路径（
/usr/bin/python3而非python3） - 如果脚本依赖特定用户环境（如ssh key、conda环境），在脚本开头显式初始化：
source /home/user/.bash_profile或export PATH="/opt/conda/bin:$PATH" - 重定向输出（
> /path/log 2>&1）是定位脚本内部错误最直接的方式
不复杂但容易忽略。抓住“服务→语法→日志→执行环境”这条线，90%的crontab不执行问题都能快速定位。
