Amazon EC2部署的Sendy定时任务反复失效 新营销邮件长期处于待发送状态

1. Cron表达式及路径配置错误 #

• 你当前使用的cron表达式*5 * * *不符合Linux crontab的标准规范：标准Linux crontab为5位结构分 时 日 月 周，若要实现每5分钟执行一次，正确写法应为*/5 * * * *
• 命令中的/php大概率是无效的PHP解释器绝对路径：cron运行时的环境变量和登录shell不同，无法识别相对路径或错误的绝对路径。可执行which php获取服务器上PHP的真实绝对路径（通常PHP7在EC2上的路径为/usr/bin/php），替换命令中的/php
• 注意校验脚本文件名拼写：Sendy官方调度脚本文件名为scheduler.php，你命令中的schedular.php存在拼写错误的可能，若文件名不匹配会直接导致脚本执行失败

2. 脚本执行死锁 #

• Sendy的调度脚本运行时会生成锁文件，避免重复执行。如果上次脚本执行时因内存不足、超时、进程被强制终止等原因异常退出，锁文件不会被自动删除，后续所有调度任务检测到锁文件存在就会直接终止，表现为任务停滞在待处理状态。你重新编辑crontab的操作如果伴随清理临时目录、重启服务等动作，会删除遗留的锁文件，因此会临时恢复正常。
• 排查方式：检查Sendy安装目录下的uploads/tmp/目录是否存在名为scheduler.lock的文件，任务停滞时如果该文件存在且更新时间远早于当前时间，即可判定为死锁问题。

3. Cron服务异常 #

• EC2实例的crond服务可能因内存不足、系统资源占用过高、系统更新等原因意外终止，而你每次重新编辑保存crontab文件时，系统会自动重启crond服务，因此任务会临时恢复正常，待crond再次异常停止后就会失效。
• 排查方式：任务失效时执行systemctl status crond（Amazon Linux/CentOS）或systemctl status cron（Ubuntu/Debian）查看cron服务运行状态，若状态为停止，可配置systemd自动拉起crond服务解决。

4. 脚本运行资源不足 #

• Sendy发送大量邮件时，调度脚本的资源占用会明显上升，若php.ini中配置的memory_limit、max_execution_time阈值过低，会导致脚本执行中途被PHP强制终止，既不会打应用日志，也会留下死锁文件。
• 可临时调整PHP配置，将memory_limit设为256M以上，max_execution_time设为0（无限制）后观察是否还会出现失效问题。

5. Cron所属用户权限问题 #

• 若你将crontab任务配置在了普通用户下，该用户可能没有Sendy目录的读写权限，脚本执行几次后遇到需要写入缓存、日志的操作时就会因权限不足终止。建议将调度任务配置在web服务器运行用户（如www-data、apache）或root用户下，同时确保/var/www/html/目录下的所有Sendy文件的所属用户和权限配置正确。

额外排查建议：不要只看Sendy的应用日志，查看系统cron运行日志定位执行报错：Amazon Linux/CentOS下查看/var/log/cron文件，Ubuntu/Debian下查看/var/log/syslog文件，过滤CRON关键词即可看到每次调度任务的执行记录和返回码，返回码127代表找不到PHP解释器，返回码1代表脚本执行报错。

内容的提问来源于stack exchange，提问作者COdeingNinja