计划任务没有执行

crontab 里写得好好的任务，到点没有任何动静，毛病常藏在四个不起眼的细节里：时区、环境变量、权限、日志。 ## 先确认任务真的注册上了 不同用户的任务各自独立，root 查别人的要带 -u 参数： crontab -l crontab -l -u www 编辑用 crontab -e；直接改 /etc/crontab 的语法多一列用户名，两种写法容易混淆。改完 systemctl status crond（Ubuntu 是 cron）确认服务本身在跑。还有一类假象：日期字段写了不存在的组合（比如 2 月 30 号），crontab 不报错但永不调度，五个字段逐个念一遍再保存。 ## 时区对不上 服务器时区是 UTC 而业务按北京时间写的计划，任务会晚八小时执行，看着就像"没跑"。用 timedatectl 看当前时区，date 核对实际时间，两者对不上先修正时区，再观察一轮任务是否按时触发。 跨时区业务更要留心：应用按北京时间算，cron 按系统时区跑，两边差着八小时时，所谓"没执行"其实是"还没到点"。 ## 环境变量与路径问题 cron 的执行环境极其精简，PATH 与登录 shell 完全不同，这是"手动能跑、cron 不跑"的头号原因。对策有两个：命令全部写绝对路径： 0 3 * * * /usr/local/bin/php /var/www/html/artisan schedule:run 或者在 crontab 开头补一行 PATH。脚本内部依赖环境变量的（比如引用 ~/.bashrc 里的配置），在 cron 下根本读不到，需要显式 source 或改用绝对配置路径。百分号在 crontab 里还有特殊含义，命令里的日期格式化要写成 \% 转义，漏了转义整段命令会被截断，属于高频暗坑。 ## 权限与日志重定向 脚本没有执行位（chmod +x 补上）、目标目录对运行用户不可写，都会静默失败。给每条任务加上输出重定向，是让问题自己浮出来的关键： 0 3 * * * /path/job.sh >> /var/log/job.log 2>&1 重定向出来的日志本身也要管理，配上 logrotate 或按天切名，否则排查用的日志反手把磁盘占满，就是另一个故事了。CentOS 的调度记录在 /var/log/cron，能看到每次触发是否发生。四项排查走完仍无头绪，就把任务临时改成每分钟一次做最小复现。每条任务上线前，把命令部分手动跑一遍，能跑通再交给 cron，是最省事的预检。