阿里云ECS的crontab定时任务为什么总是不执行？时区、环境变量到底哪个才是坑？

阿里云ECS的crontab定时任务为什么总是不执行？时区、环境变量到底哪个才是坑？

直接给结论：crontab定时任务不执行，九成不是crontab坏了，而是「环境变量缺失、路径写不对、时区不一致」这三个坑在作怪。阿里云ECS本身跑cron很稳定，别急着怀疑云服务器有问题，先按下面几条排查。

1. 先看时区对不对。阿里云ECS默认镜像时区是UTC，而国内业务往往按北京时间设任务，结果凌晨2点的任务变成上午10点跑。用 timedatectl 查一下，必要时执行 timedatectl set-timezone Asia/Shanghai，改完重启crond服务。
2. 环境变量和你登录时不一样。你手动SSH登录能跑的脚本，cron里可能找不到命令，因为cron的PATH非常精简。脚本里python、node等命令请写绝对路径，或在crontab顶部显式声明 PATH= 和 SHELL=。
3. 输出重定向留证据。每条任务后面加上 >> /var/log/myjob.log 2>&1，跑没跑、报什么错一目了然。没有日志的排查全靠猜，效率极低。
4. 注意文件权限和换行符。脚本要有执行权限（chmod +x），Windows下编辑过的脚本可能带CRLF换行符，放上去直接报错。建议在ECS上直接用vim写或先 dos2unix 一下。
5. 别和云监控打架。有人习惯用「阿里云云助手」或OOS定时运维来替代cron，其实两者可以共存：单机任务用cron，批量操作用云助手更方便。腾讯云对应的是CVM上的TAT自动化工具，思路一样，都是云端下发命令执行，适合管多台服务器。
6. 重要任务做兜底。cron只保证触发，不保证成功。关键任务（如数据库备份）最好加执行结果通知，或配合云监控的自定义上报做告警。

注意：

• 改完crontab要确认crond服务在运行：systemctl status crond，Docker容器里还要额外确认容器内cron进程已启动。
• 不要把任务频率设得比任务执行时间还短，任务堆积会互相卡死。
• 改时区只影响新任务的判断，已写好的crontab时间要重新核对一遍。

总结：crontab不执行先查时区、再查环境变量、最后留好日志，基本百发百中。服务器多了以后，可以用云助手/TAT这类云端命令工具统一管理，比一台台登机器省心得多。

参考价格对比（以官方活动页实时价格为准）：