我在nginx下运行着由三个mongrels组成的集群，我使用Capistrano 2.4.3部署了该应用程序。当我在运行系统的情况下"上限部署"时，行为是：

• 该应用已部署。代码已成功更新。
• 服务器：[" myip"]
• [myip]执行命令
• ** [out :: myip]停止端口9096
• ** [out :: myip]停止端口9097
• ** [out :: myip]停止端口9098
• ** [out :: myip]已启动端口9096
• ** [out :: myip]已启动端口9097
• ** [out :: myip]已启动端口9098
• 我立即在服务器上检查并发现Mongrel仍在运行，并且前三个实例的PID文件仍然存在。
• 不久之后(不到一分钟)，我发现Mongrel不再运行，PID文件消失了，并且无法重新启动。
• 如果我手动在服务器上启动杂种，则该应用程序启动正常。

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

编辑：这是答案：

在"重新启动"任务中，mongrel_cluster只需执行以下操作：

def run
   stop
   start
 end

在调用"开始"之前，它不会等待或者检查进程是否已退出。这是一个已知的错误，其中提交了出色的补丁程序。我将补丁应用到Mongrel Cluster，问题消失了。

解决方案

我讨厌这么基础，但是听起来好像pid文件在尝试启动时仍然悬而未决。确保手动关闭杂种。手动清理pid文件。然后进行上限部署。

首先，仅调用cap deploy：restart来缩小测试范围。我们可能想要通过--debug选项在远程执行之前进行提示，或者通过--dry-run选项只是为了查看在调整设置时发生了什么。

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

• ：runner变量被显式设置为nil-是否有特定的原因？
• Capistrano 2.4为：admin_runner变量引入了新的行为。在没有看到整个配方的情况下，这可能与问题有关吗？

:runner vs. :admin_runner (from capistrano 2.4 release)
  Some cappers have noted that having deploy:setup and deploy:cleanup run as the :runner user messed up their carefully crafted permissions. I agreed that this was a problem. With this release, deploy:start, deploy:stop, and deploy:restart all continue to use the :runner user when sudoing, but deploy:setup and deploy:cleanup will use the :admin_runner user. The :admin_runner variable is unset, by default, meaning those tasks will sudo as root, but if you want them to run as :runner, just do “set :admin_runner, runner”.

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

我们可以通过在Capistrano配方中添加以下内容，明确地告诉mongrel_cluster配方在开始之前删除pid文件：

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

这使它将--clean选项传递给mongrel_cluster_ctl。

我回过头看了看我的一个部署配方，发现我还改变了重启任务的工作方式。查看"杂种用户"组中的以下消息：

杂种用户重启讨论

以下是我的deploy：restart任务。我承认这有点骇人听闻。

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

无论哪种方式，我的杂种狗都会在上一个stop命令完成关闭所有命令之前启动。

如果要花2.5秒钟以上的时间来阻止所有运行中的杂种动物，sleep 2.5不是一个好的解决方案。

似乎需要：

stop && start

与

stop; start

(这是bash的工作方式，&&等待第一个命令完成且没有错误，而";"仅运行下一个命令)。

我想知道是否有：

wait cluster_stop
then cluster_start

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