Question

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

已部署该应用。代码已成功更新。
在上限部署输出中，有以下内容：
- 执行“sudo -p”sudo密码：' mongrel_rails cluster :: restart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml“
- servers：[“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

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

Answer 1

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

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

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

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

mongrel users discussion of 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文件或mongrel进程的权限问题，但很难确切知道。引起我注意的几件事是：

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

：runner vs.：admin_runner （来自capistrano 2.4 release）一些封顶人员已经注意到部署：设置和部署：清理运行时：runner用户搞砸了他们精心设计的权限。我同意这是一个问题。在此版本中，部署：start，deploy：stop和deploy：restart all在sudoing时继续使用：runner用户，但是部署：setup和deploy：cleanup将使用：admin_runner用户。：admin_runner变量默认情况下是未设置的，这意味着这些任务将以root用户身份执行，但如果您希望它们以：run运行，只需执行“set：admin_runner，runner”。

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

Answer 3

无论哪种方式，我的杂种都在前一个停止命令完成关闭之前启动。

睡眠2.5不是一个好的解决方案，如果停止所有正在运行的杂种的时间超过2.5秒。

似乎需要：

stop && start

VS

stop; start

（这就是bash的工作原理，＆amp;＆amp;等待第一个命令完成w / o错误，而“;”只是运行下一个命令。）

我想知道是否有：

wait cluster_stop
then cluster_start

Answer 4

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

Answer 5

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

Capistrano没有正确重启Mongrel集群

5 个答案: