先查crond服务状态，若未运行则任务必不执行；再确认环境变量、绝对路径、语法格式（用户级5字段无用户名）、日志重定向是否完备。
crontab -e 编辑后任务不执行？先查 crond 服务状态
任务写进 crontab -e 却没反应，90% 是因为 crond（或 cron）根本没在跑。它不是“配置完就自动活过来”的服务。
- 运行
systemctl status crond（CentOS/RHEL）或systemctl status cron（Debian/Ubuntu），看是否显示active (running) - 若为
inactive (dead)，立刻执行sudo systemctl start crond或sudo systemctl start cron - 加开机自启：运行
sudo systemctl enable crond或sudo systemctl enable cron - 验证进程是否存在：
ps aux | grep crond，应看到类似/usr/sbin/crond -n的行
为什么脚本在终端能跑，放进 crontab 就报 command not found
cron 环境极简，默认 PATH 通常只有 /usr/bin:/bin，不会加载你的 ~/.bashrc 或 /etc/profile。
- 在
crontab -e文件顶部显式声明环境变量，例如：SHELL=/bin/bashPATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin - 所有命令路径必须写绝对路径：
/usr/bin/python3而非python3，/usr/bin/git而非git - 避免用
~，改用/home/username/或$HOME（但需确认 shell 支持，推荐前者） - 测试方式：在脚本开头加
env >> /tmp/cron_env.log，对比终端执行时的env输出
/etc/crontab 和 crontab -e 的格式区别在哪
二者字段数不同，混用会直接静默失败——这是最常被忽略的语法坑。
-
crontab -e（用户级）：5 个时间字段 + 命令，共 6 列，**没有用户字段**
示例：0 2 * * * /bin/bash /home/user/backup.sh -
/etc/crontab（系统级）：5 个时间字段 + **用户名** + 命令，共 7 列
示例：30 3 * * * root /usr/bin/find /tmp -type f -mtime +7 -delete -
/etc/cron.d/下的文件：格式同/etc/crontab，必须含用户名字段，且文件名不能含点（如mytask可，mytask.conf会被忽略） - 误把用户级格式写进
/etc/crontab，会导致整行被跳过，/var/log/cron里可能只记一句bad hour或更模糊的错误
日志和调试：别等出问题才想起加重定向
cron 默认不输出任何提示，失败也不报错，全靠你主动捕获。
- 每条任务末尾务必加上日志重定向：
>> /path/to/log 2>&1，例如：0 4 * * * /usr/local/bin/backup.sh >> /var/log/backup_cron.log 2>&1 - 日志路径要确保目标用户有写权限（比如
/var/log/下普通用户通常无权写，建议用/home/user/logs/） - 查 cron 自身日志：
sudo tail -f /var/log/cron（RHEL/CentOS）或sudo journalctl -u cron -f（Debian/Ubuntu） - 临时测试可用
* * * * *（每分钟）+ 简单命令（如date >> /tmp/test.log），确认机制通了再调正式时间
实际部署时，最容易被绕过的不是语法，而是环境隔离——cron 不是你终端的延伸，它是一套独立、精简、不声不响的执行环境。路径、变量、权限、日志，缺一不可。
