SolidQueue服务异常终止问题分析与解决方案

问题现象

在使用SolidQueue作为Rails应用的后台任务处理系统时，部分用户报告了服务异常终止的问题。具体表现为：

1. 服务进程突然停止工作，但systemd状态显示仍为"active (running)"
2. 工作进程(worker)运行时间不稳定，从几分钟到几小时不等
3. 系统日志中缺乏明确的错误信息
4. 问题在新服务器迁移后尤为明显

根本原因分析

经过技术排查，发现这类问题通常由以下两种场景导致：

1. SSH会话终止导致服务停止

当通过SSH会话启动服务时，如果未正确配置linger设置，SSH会话结束会导致所有用户级systemd服务被终止。这是Linux系统默认的安全行为，但会对后台服务造成影响。

2. Docker环境中的exec命令问题

在Docker容器(特别是基于Alpine的容器)中，如果使用exec命令启动Rails进程(如通过bin/dev脚本)，可能会导致以下连锁反应：

• 执行其他容器操作(如文件监视、测试运行等)时意外终止Rails主进程
• SolidQueue工作进程随之停止
• 日志中仅显示工作进程退出信息，难以追踪根本原因

解决方案

针对SSH会话问题

执行以下命令启用用户服务的linger功能：

sudo loginctl enable-linger <deploy用户名>

此命令确保即使用户注销后，用户级systemd服务仍能继续运行。

针对Docker环境问题

修改服务启动方式，避免使用exec命令：

1. 检查并修改bin/dev脚本，移除exec关键字
2. 确保Dockerfile或启动脚本中不直接使用exec启动应用
3. 对于Foreman等工具，检查Procfile配置

虽然这会略微增加内存开销(保留shell进程)，但对大多数应用影响可以忽略不计。

配置建议

对于生产环境，推荐以下SolidQueue配置最佳实践：

default: &default
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 3
      processes: <%= ENV.fetch("JOB_CONCURRENCY", 1) %>
      polling_interval: 0.1

同时确保在Rails配置中启用详细日志：

config.solid_queue.silence_polling = false

系统服务配置示例

以下是经过验证可靠的systemd服务配置模板：

[Unit]
Description=SolidQueue后台服务
After=syslog.target network.target

[Service]
Type=simple
Environment=RAILS_ENV=production
WorkingDirectory=/path/to/app/current
ExecStart=/path/to/bundle exec rake solid_queue:start
RestartSec=1
Restart=on-failure

StandardOutput=append:/path/to/log/solid_queue.log
StandardError=append:/path/to/log/solid_queue.log

[Install]
WantedBy=default.target

总结