排查AWS ECS部署的Bitnami Canvas-LMS邮件发送失败问题

基于你描述的情况（Bitnami Canvas-LMS部署在AWS ECS，SMTP配置完成、mailx可正常发信、邮件任务已进入delayed_job队列但未发送），可以从以下几个维度排查：

• 检查Delayed Job进程运行状态
  Canvas依赖delayed_job处理异步邮件任务，先确认该进程是否正常运行。在ECS容器内执行命令：

  ps aux | grep delayed_job
  

  若没有进程输出，说明delayed_job未启动——需检查Bitnami镜像的启动脚本是否包含delayed_job的启动逻辑，或手动启动进程：

  bundle exec rake jobs:work
  

  同时查看delayed_job.log中是否有进程崩溃、重启的报错信息。

• 验证Delayed Job队列监听配置
  Canvas的邮件任务默认进入:mailer队列，需确认delayed_job是否监听该队列。检查配置文件config/delayed_job.yml或对应的环境变量（如DELAYED_JOB_QUEUES），确保队列列表包含:mailer。若仅监听了特定队列，邮件任务会因无人处理而堆积。

• 核对SMTP配置的实际生效情况
  即使按官方指引配置了outgoing_mail.yml，也可能存在配置未生效或细节错误：

  1. 在容器内启动Rails控制台：

     rails console production
     

  2. 执行命令查看实际生效的SMTP配置：

     ActionMailer::Base.smtp_settings
     

  对比输出与outgoing_mail.yml的配置，重点检查端口（465/587是否混淆）、SSL/TLS开关、认证方式（plain/login/cram-md5）、账号密码是否正确。另外需注意：Bitnami镜像可能通过CANVAS_LMS_SMTP_*环境变量覆盖配置文件，若存在这类变量需确认其值无误。

• 查看Canvas核心日志的错误信息
  除了delayed_job.log，检查Canvas的生产日志（如log/production.log），里面会记录邮件任务执行时的具体错误——比如SMTP连接超时、认证失败、收件方服务器拒收等。这些错误可能不会在delayed_job的队列日志中体现，但会导致任务执行失败。

• 检查队列任务的失败状态
  若delayed_job执行邮件任务失败，任务会被标记为失败或进入重试队列。在Rails控制台执行以下命令排查：

  # 查看所有队列任务
  Delayed::Job.all
  # 查看指定任务的错误详情（替换id为任务ID）
  Delayed::Job.find(id).last_error
  

  通过last_error字段可获取任务失败的具体原因，比如SMTP服务器返回的错误码、认证失败提示等。

• 排查ECS网络与安全限制
  虽然mailx能正常发信，但Canvas进程的网络路径可能不同：

  • 检查ECS容器所在的安全组是否允许出站访问SMTP服务器的对应端口（如587、465）；
  • 确认SMTP服务器是否限制了ECS容器的公网IP（可将容器IP加入SMTP服务器的白名单）；
  • 在容器内测试SMTP服务器的连通性：

    telnet smtp.example.com 587
    

    若无法连接，说明存在网络层面的阻断。

• 确认Bitnami镜像的配置生效逻辑
  修改outgoing_mail.yml后，需确保配置已生效：

  • 重启ECS容器，或在容器内执行touch tmp/restart.txt触发Rails重新加载配置；
  • 检查outgoing_mail.yml的文件权限，确保delayed_job进程的运行用户（通常是daemon或bitnami）拥有读取权限。

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