ruby-on-rails - CapistranoがMongrelクラスターを適切に再起動しない

Question

nginxで実行されている3つの雑種のクラスターがあり、Capistrano2.4.3を使用してアプリをデプロイします。実行中のシステムがあるときに「キャップデプロイ」すると、動作は次のようになります。

1. アプリがデプロイされます。コードは正常に更新されました。

2. cap deployの出力には、次のものがあります。

   • "sudo -p'sudo password：' 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がまだ実行中であり、前の3つのインスタンスのPIDファイルがまだ存在していることがわかります。
4. しばらくして（1分未満）、Mongrelが実行されなくなり、PIDファイルがなくなり、再起動に失敗しました。
5. サーバー上で手動で雑種犬を起動すると、アプリは正常に起動します。

'mongrel_rails cluster :: restart'は、クラスターの再起動を試みる前に、完全な停止を適切に待機していないようです。この問題を診断して修正するにはどうすればよいですか？

編集：答えは次のとおりです。

mongrel_clusterは、「再起動」タスクで、これを実行するだけです。

 def run
   stop
   start
 end

「開始」を呼び出す前に、プロセスが終了したことを確認するための待機やチェックは行いません。これは、未解決のパッチが提出された既知のバグです。パッチをMongrelClusterに適用すると、問題は解消されました。

Answer 1

capistrano レシピに以下を追加することで、開始前に pid ファイルを削除するよう mongrel_cluster レシピに明示的に指示できます。

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

これにより、 --clean オプションが mongrel_cluster_ctl に渡されます。

戻ってデプロイ レシピの 1 つを確認したところ、再起動タスクの動作方法も変更されていることに気付きました。mongrel ユーザー グループの次のメッセージを見てください。

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

Answer 2

いずれにせよ、前の停止コマンドがすべてのシャットダウンを完了する前に、雑種が起動しています。

実行中の雑種をすべて停止するのに 2.5 秒以上かかる場合、sleep 2.5 は適切な解決策ではありません。

次のものが必要なようです。

stop && start

対。

stop; start

（これがbashの仕組みです。&&は最初のコマンドがエラーなしで終了するのを待ちますが、「;」は単に次のコマンドを実行します）。

私はあるのだろうか：

wait cluster_stop
then cluster_start

Answer 3

まず、 を呼び出すだけで、テストの範囲を狭めますcap deploy:restart。--debugリモート実行の前にプロンプ​​トを表示するオプションを渡すか--dry-run、設定を微調整するときに何が起こっているかを確認するためだけにオプションを渡すことができます。

一見すると、これは pid ファイルまたは mongrel プロセスのアクセス許可の問題のように思えますが、確実に知ることは困難です。私の目を引くいくつかのことは次のとおりです。

• :runner変数は明示的に設定されていnilます-- これには特定の理由がありましたか?
• Capistrano 2.4 では、変数の新しい動作が導入されました:admin_runner。レシピ全体を表示せずに、これはおそらくあなたの問題に関連していますか?

  :runner vs. :admin_runner ( capistrano 2.4 リリースから) 一部の capper は、 deploy:setup と deploy:cleanup を :runner ユーザーとして実行すると、慎重に作成されたパーミッションが台無しになったと指摘しています。私はこれが問題であることに同意しました。このリリースでは、deploy:start、deploy:stop、および deploy:restart はすべて、sudo 時に引き続き :runner ユーザーを使用しますが、deploy:setup および deploy:cleanup は :admin_runner ユーザーを使用します。:admin_runner 変数はデフォルトで設定されていません。つまり、これらのタスクは root として sudo しますが、:runner として実行したい場合は、「set :admin_runner, runner」を実行してください。

次に何をすべきかについての私の推奨事項。雑種を手動で停止し、PID をクリーンアップします。雑種を手動で起動します。次に、cap deploy:restart問題をデバッグしながら実行を続けます。必要に応じて繰り返します。

Answer 4

私はとても基本的なことを嫌いますが、起動しようとしているときに pid ファイルがまだぶら下がっているように思えます。雑種が手で止められていることを確認してください。pid ファイルを手動でクリーンアップします。次に、キャップ展開を行います。

Answer 5

良い議論: http://www.ruby-forum.com/topic/139734#745030