Linux cron任务失败七成以上源于权限问题：需依次确认cron服务是否运行、用户是否被/etc/cron.deny禁止、脚本是否具备执行权限及绝对路径、环境变量（如PATH）是否显式声明。
Linux中cron任务失败，七成以上源于权限相关环节出错——不是服务没开、用户被拦，就是脚本没权跑、环境找不到命令。关键不在“会不会写crontab”，而在“能不能稳稳执行”。
确认cron服务是否真正运行
很多任务“不执行”，其实crond根本没在跑。最小化系统、Docker容器、部分云镜像默认不启用该服务。
- Debian/Ubuntu执行：systemctl status cron；RHEL/CentOS执行：systemctl status crond
- 若显示 inactive (dead)，立即启动：sudo systemctl start cron（或 crond）
- 务必设为开机自启：sudo systemctl enable cron，否则重启后又失效
- 普通用户无法启停服务，service crond start 在非root下会静默失败，不能靠它判断状态
检查用户是否被允许使用cron
cron不是所有用户都能用，系统通过 /etc/cron.allow 和 /etc/cron.deny 控制准入。
- 若 /etc/cron.allow 存在，只有其中列出的用户才可使用 crontab
- 若 /etc/cron.deny 存在且非空，而你的用户名在里面，就明确被禁止了
- 检查方式：grep "$(whoami)" /etc/cron.deny，有输出即说明被拦住，需手动删掉该行
确保脚本与路径权限到位
服务开着、用户合法，脚本本身没权限照样失败。
- 脚本必须有执行权限：chmod +x /path/to/script.sh
- 脚本中所有调用的命令、文件、目录，都得用绝对路径（如 /usr/bin/python3，而非 python3）
- 确保脚本访问的目录可读可执行（cd /data 要求 /data 有 x 权限），日志文件所在目录对运行用户要有 w 权限
- 特别注意：/var/spool/cron 目录可能被加了不可修改属性，用 lsattr /var/spool/cron 查看，若含 i 或 a，需先执行 chattr -ia /var/spool/cron
补全环境变量，避免命令找不到
cron 启动的是极简 shell（/bin/sh），PATH 极窄（通常仅 /usr/bin:/bin），不加载 .bashrc、.profile，也不继承终端里的环境。
- 常见现象：手动能跑，cron里报 command not found 或 No such file or directory（比如找不到 mysqldump、node）
- 稳妥做法：在 crontab 文件开头显式声明环境变量：
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
HOME=/home/username - 或改用 bash -lc 加载登录环境：
0 2 * * * bash -lc '/path/to/script.sh > /tmp/log 2>&1'
