Capistrano 未正确重启 Mongrel 集群

Question

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

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

2. 在 cap 部署输出中，有这样的内容：

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

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

编辑：答案如下：

mongrel_cluster，在“重新启动”任务中，简单地执行以下操作：

 def run
   stop
   start
 end

在调用“start”之前，它不会进行任何等待或检查以查看进程是否退出。这是 已提交未完成补丁的已知错误. 。我将补丁应用于 Mongrel Cluster，问题就消失了。

Answer 1

您可以通过在 capistrano 配方中添加以下内容来显式告诉 mongrel_cluster 配方在启动前删除 pid 文件：

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

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

我回去查看了我的部署方案之一，发现我还更改了重新启动任务的工作方式。看看 mongrel 用户组中的以下消息：

杂种用户讨论重启

以下是我的部署：重新启动任务。我承认这有点黑客行为。

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 2

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

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

• 这 :runner 变量明确设置为 nil ——这其中有什么具体原因吗？
• 卡皮斯特拉诺 2.4 引入了新的行为 :admin_runner 多变的. 。如果没有看到整个食谱，这可能与您的问题有关吗？

  : 跑步者 vs 跑步者:admin_runner （从 卡皮斯特拉诺 2.4 发布) 一些封盖者指出，以 ：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

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

如果停止所有正在运行的杂种程序需要超过 2.5 秒的时间，那么 sleep 2.5 并不是一个好的解决方案。

似乎需要：

stop && start

与

stop; start

（这就是 bash 的工作原理，&& 等待第一个命令完成而不会出现错误，而“;”只是运行下一个命令）。

我想知道是否有：

wait cluster_stop
then cluster_start

Answer 4

我不想这么简单，但听起来当它试图启动时 pid 文件仍然存在。确保用手阻止杂种。手动清理 pid 文件。然后进行上限部署。

Answer 5

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