RoR 6生产环境Delayed Jobs运行数日后无故停止问题咨询

• 内存溢出被系统强制回收：Digital Ocean低配置Droplet内存余量有限，Delayed Job长时间运行如果遇到任务存在内存泄漏、批量处理大文件/大查询的场景，内存占用会持续攀升，触发Linux OOM Killer机制时会被系统直接杀掉，应用层不会留存崩溃日志，可执行dmesg | grep -i oom-kill查看系统日志确认。
• 未捕获的运行时错误崩溃：常见场景包括数据库连接闲置超时被服务端断开后没有触发自动重连、第三方依赖调用触发底层段错误、队列任务抛出未被rescue的致命异常，都会直接导致Delayed Job主进程退出。RoR 6默认的数据库连接池配置如果和Delayed Job的worker数不匹配，长连接耗尽时也会触发进程崩溃。
• 外部信号误杀：系统自动安全更新重启底层依赖、logrotate切割日志时发送错误信号、其他运维脚本误匹配Delayed Job的PID执行kill操作，都会导致进程无预警终止。
• 守护进程模式自身缺陷：Delayed Job默认的daemonize模式没有内置健康检查，长时间运行后可能出现PID文件脏数据、父进程异常退出的情况，子进程沦为僵尸进程后会被系统自动回收。

当前cron配置存在两处核心错误：

1. 整段执行命令被单引号包裹，cron会将带单引号的完整字符串识别为可执行文件路径，根本找不到对应程序，任务自然无法触发
2. cron执行任务时默认加载的环境变量PATH不包含Ruby、Bundler的可执行路径，即便去掉引号，也会出现找不到命令的报错

可参考以下修正后的配置，注意根据自己的Ruby安装方式调整环境加载路径：

0 1 * * * /bin/bash -c 'cd /var/path/to/rails_project && source ~/.rvm/scripts/rvm && RAILS_ENV=production bundle exec bin/delayed_job restart'

如果是系统包管理器安装的Ruby，可替换为bundle命令的绝对路径，避免依赖cron默认PATH查找。

日常排查cron问题可参考两个方法：

• 系统默认会记录cron所有执行日志，Debian/Ubuntu系统可查看/var/log/syslog、CentOS/RHEL系统可查看/var/log/cron，搜索CRON关键字即可确认任务是否触发、执行时返回什么错误
• 配置完成后可先将调度时间调整为当前时间2分钟后做测试，确认执行正常后再改回每日凌晨1点的调度规则

更稳妥的生产环境方案是用systemd托管Delayed Job进程，配置Restart=always策略，无论进程因为什么原因退出都会被立即拉起，可靠性远高于每日定时重启，也能避免进程挂掉后到定时重启时间窗口内的服务不可用问题。

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