5

我有一个在 nginx 下运行的由三个杂种组成的集群，我使用 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

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

4

5 回答 5

4

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

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

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

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

杂种用户讨论重启

以下是我的 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
于 2008-10-01T14:42:16.323 回答
1

首先，通过仅调用cap deploy:restart. 您可能希望--debug在远程执行之前将选项传递给提示，或者--dry-run只是在调整设置时查看发生了什么的选项。

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

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

    :runner 与 :admin_runner（来自capistrano 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接下来，一边调试问题一边继续运行。根据需要重复。

于 2008-10-01T02:37:48.937 回答
1

无论哪种方式，我的杂种在上一个停止命令完成关闭它们之前就开始了。

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

似乎需要：

stop && start

对比

stop; start

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

我想知道是否有一个：

wait cluster_stop
then cluster_start
于 2008-11-03T00:10:49.313 回答
0

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

于 2008-09-30T22:36:00.903 回答
0

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

于 2008-11-03T00:12:40.807 回答