linux计划任务执行失败主因是权限问题，需依次确认cron服务运行状态、用户准入权限、脚本及路径权限、环境变量缺失；服务未启、用户被deny、脚本无x权限、命令非绝对路径、path过窄均会导致失败。
Linux计划任务执行失败，十次里有七次是权限问题——不是脚本没权限，就是环境没权限，或是用户根本没被允许跑cron。
确认 cron 服务是否真正运行
很多“任务不执行”其实压根不是脚本的问题，而是 crond 根本没在跑。最小化安装、docker 容器、某些云镜像默认都不启用 cron 服务。
- 查状态：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 存在且未空，而你的用户名在里面，那你就被明确禁止了
- 多数系统只维护 cron.deny，默认允许所有人——但如果你被误加进去了，就得手动删掉
- 检查方式：grep “$(whoami)” /etc/cron.deny，有输出就说明被拦住了
脚本与路径权限必须到位
即使服务开着、用户合法，脚本本身没权限照样失败。
- 脚本必须有执行权限：chmod +x /path/to/script.sh
- 脚本中所有调用的命令、文件、目录，都得用绝对路径（比如 /usr/bin/python3 而非 python3）
- 确保脚本访问的目录可读可执行（cd /data 要求 /data 有 x 权限）、日志文件可写（/var/log/myscript.log 所在目录对运行用户要有 w 权限）
- 特别注意 /var/spool/cron 目录可能被加了不可修改属性：lsattr /var/spool/cron，若看到 i 或 a，需先执行 chattr -ia /var/spool/cron
环境变量缺失是最隐蔽的权限类问题
crond 启动的是极简 shell（/bin/sh），PATH 极窄（通常仅 /usr/bin:/bin），不加载 .bashrc、.profile，也不继承你终端里的环境。
- 常见现象：手动能跑，cron 里报 command not found 或 No such file or Directory（比如找不到 sudo、mysqldump、node）
- 解决方法一：在 crontab 中显式声明 PATH：
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
0 2 * * * /path/to/script.sh > /tmp/log 2>&1 - 解决方法二：用 bash -lc 加载登录环境：
0 2 * * * bash -lc ‘/path/to/script.sh > /tmp/log 2>&1’ - 验证方式：在脚本开头加 echo $PATH >> /tmp/env.log，对比手动执行时的输出