Capistrano 没有正确重启 Mongrel 集群

Question

我有一个在 nginx 下运行的由三个 mongrel 组成的集群，我使用 Capistrano 2.4.3 部署应用程序。当我在有一个正在运行的系统时“限制部署”时，行为是：

1. 应用程序已部署。代码更新成功。

2. 在 cap deploy 输出中，有这样的：

   • 执行“sudo -p 'sudo 密码：' mongrel_rails cluster::restart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml"
   • 服务器：["myip"]
   • [myip] 执行命令
   • ** [out :: myip] 停止端口 9096
   • ** [out :: myip] 停止端口 9097
   • ** [out :: myip] 停止端口 9098
   • ** [out :: myip] 已启动端口 9096
   • ** [out :: myip] 已启动端口 9097
   • ** [out :: myip] 已启动端口 9098
3. 我立即检查服务器，发现 Mongrel 仍在运行，并且前三个实例的 PID 文件仍然存在。
4. 不久之后（不到一分钟），我发现 Mongrel 不再运行，PID 文件不见了，并且无法重新启动。
5. 如果我在服务器上手动启动 mongrel，应用程序启动得很好。

'mongrel_rails cluster::restart' 似乎没有正确等待句号 在尝试重新启动集群之前。如何诊断和解决此问题？

编辑：这是答案：

mongrel_cluster，在“重启”任务中，简单地这样做：

 def run
   stop
   start
 end

在调用“start”之前，它不会等待或检查进程是否退出。这是a known bug with an outstanding patch submitted。我将补丁应用到 Mongrel Cluster，问题就消失了。

Answer 1

我讨厌这么简单，但听起来 pid 文件在尝试启动时仍然挂起。确保手动停止杂种。手动清理 pid 文件。然后进行上限部署。

Answer 2

首先，通过仅调用cap deploy:restart 来缩小您的测试范围。您可能希望通过--debug 选项在远程执行之前进行提示，或者通过--dry-run 选项来查看在您调整设置时发生了什么。

乍一看，这听起来像是 pid 文件或 mongrel 进程的权限问题，但很难确定。引起我注意的几件事是：

• :runner 变量显式设置为 nil -- 是否有特定原因？
• Capistrano 2.4 为:admin_runner 变量引入了新行为。没有看到整个食谱，这可能与您的问题有关吗？

  :runner vs. :admin_runner（来自capistrano 2.4 release） 一些封盖者注意到，以 :runner 用户身份运行 deploy:setup 和 deploy:cleanup 会破坏他们精心设计的权限。我同意这是一个问题。在此版本中，deploy:start、deploy:stop 和 deploy:restart 在 sudoing 时都继续使用 :runner 用户，但 deploy:setup 和 deploy:cleanup 将使用 :admin_runner 用户。 :admin_runner 变量默认未设置，这意味着这些任务将以 root 身份执行，但如果您希望它们以 :runner 身份运行，只需执行“set :admin_runner, runner”。

我对下一步做什么的建议。手动停止杂种并清理 PID。手动启动杂种。接下来在调试问题的同时继续运行cap deploy:restart。根据需要重复。

Answer 3

您可以通过在 capistrano 配方中添加以下内容来明确告诉 mongrel_cluster 配方在开始之前删除 pid 文件：

# helps keep mongrel pid files clean
set :mongrel_clean, true

这会导致它将 --clean 选项传递给 mongrel_cluster_ctl。

我回去查看了我的一个部署配方，发现我也改变了重启任务的工作方式。查看 mongrel 用户组中的以下消息：

mongrel users discussion of restart

以下是我的 deploy:restart 任务。我承认这有点像 hack。

namespace :deploy do
  desc "Restart the Mongrel processes on the app server."
  task :restart, :roles => :app do
    mongrel.cluster.stop
    sleep 2.5
    mongrel.cluster.start
  end
end

Answer 4

不管怎样，我的杂种在上一个停止命令完成关闭它们之前就开始了。

sleep 2.5 不是一个好的解决方案，如果它需要超过 2.5 秒来停止所有正在运行的杂种。

似乎需要：

stop && start

对比

stop; start

（这就是 bash 的工作方式，&& 等待第一个命令完成而没有错误，而“;”只是运行下一个命令）。

不知道有没有：

wait cluster_stop
then cluster_start

Answer 5

好讨论：http://www.ruby-forum.com/topic/139734#745030