90%以上宝塔计划任务不执行是crond服务未运行或脚本在crond环境下不可见/不可执行：需检查systemctl status crond状态，确保active(running)；使用绝对路径、赋予脚本执行权限、显式调用解释器；排查pam认证失败（如root密码过期）、时区不一致及宝塔自身cron.log日志。
宝塔计划任务不执行，90% 以上是 crond 服务没跑起来，或脚本在 crond 环境下根本找不到、跑不动。不是面板坏了，也不是你设置错了，而是底层 Linux 的定时调度引擎压根没工作，或者它“看不见”你的脚本。
crond 服务是否真的在运行
宝塔的计划任务只是个前端界面，真正干活的是系统级的 crond 进程。它一旦停止，所有任务都会静默失效，面板上连报错都不会有。
- 用
systemctl status crond查状态，看到active (running)才算正常；若显示inactive (dead)或not found，说明服务根本没启。 - CentOS/RHEL 8+ 或某些新版系统可能用
cronie包，服务名是crond；Debian/Ubuntu 则常用cron服务名，得试systemctl status cron。 - 启动后别忘了加自启：
systemctl enable crond（或cron），否则重启服务器就又挂了。
脚本路径和执行权限是否正确
宝塔里填的“脚本内容”，在 crond 环境下是以独立 shell 启动的，没有当前工作目录、没有用户登录时的 $PATH、也不会自动 source ~/.bashrc —— 所以相对路径、缺解释器、没权限，全都会失败且不报错。
- 必须用绝对路径，比如
/www/wwwroot/site.com/backup.sh，不能写./backup.sh或backup.sh。 - Shell 脚本要加执行权限：
chmod +x /www/wwwroot/site.com/backup.sh。 - PHP 脚本推荐显式调用解释器：
/usr/bin/php /www/wwwroot/site.com/cron.php，别只写php cron.php（crond 环境里很可能找不到php命令）。 - 如果脚本依赖环境变量（如
HOME、PATH），得在脚本开头手动设置，或用/bin/bash -c 'export PATH=...; /path/to/script.sh'包一层。
crond 日志里有没有 PAM 认证失败
当你发现 crond 明明 running，但任务就是不触发，且日志里反复出现 PAM ERROR 或 Authentication token is no longer valid，大概率是 root 密码过期了 —— 这在 CentOS/RHEL 类系统上很常见，尤其启用了密码策略后。
- 查日志：
tail -f /var/log/cron，重点看有没有含PAM、expired password的行。 - 确认 root 密码状态：
chage -l root，若看到Password expires : [date]且已过期，就得重设。 - 重置密码：
passwd，输两遍新密码；想一劳永逸可设永不过期：chage -M 99999 root。 - 改完密码后，必须重启
crond：systemctl restart crond，否则旧认证上下文还在缓存里。
宝塔自身 cron.log 是否有线索
宝塔会把任务启动/结束记录到自己的日志里，路径是 /www/wwwlogs/cron.log。它不反映底层失败原因，但能帮你确认：任务到底有没有被面板触发？有没有卡在“开始执行”就没了？
- 执行
tail -f /www/wwwlogs/cron.log，然后在面板里手动点击“执行”一次，看日志是否新增一行“开始执行”。没有，说明面板层就断了（比如任务被禁用、面板进程异常）。 - 如果有“开始执行”但没“执行结束”，大概率是脚本卡死、超时或被 kill；如果有“执行结束”但结果不对，问题就在脚本逻辑或环境里。
- 注意：这个日志不会显示 stderr 输出，所以脚本里的
echo或var_dump默认看不到，得重定向到文件，比如/usr/bin/php /path/to/script.php >> /tmp/cron_debug.log 2>&1。
最常被忽略的一点：crond 不认面板里显示的“北京时间”，它只认系统 localtime。哪怕宝塔右上角时间是对的，只要 /etc/localtime 指向错误时区，任务就会错峰执行甚至完全跳过。修时区比修脚本还容易漏掉。
