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]执行命令
   • ** [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

它不会执行任何等待或检查以查看进程在调用“启动”之前是否退出。 这是一个已知错误，具有突出的问题补丁已提交。 我将补丁应用于 Mongrel Cluster，问题就消失了。

Answer 1

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

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

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

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

mongrel 用户讨论的restart

下面是我的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

Answer 2

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

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

• :runner 变量被显式设置为 nil——这有什么具体原因吗？
• Capistrano 2.4 引入了 :admin_runner 变量的新行为。 如果没有看到整个食谱，这可能与您的问题有关吗？

  <块引用>

  :runner 与 :admin_runner（来自 capistrano 2.4 版本)
  一些封顶者注意到，以 :runner 用户身份运行部署：设置和部署：清理会弄乱他们精心设计的权限。 我同意这是一个问题。 在此版本中，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

vs.

stop; start

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

我想知道是否有：

wait cluster_stop
then cluster_start

Answer 4

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

Answer 5

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