Capistrano неправильно перезапускает кластеры Mongrel

Question

У меня есть кластер из трех шавок, работающих под nginx, и я развертываю приложение, используя Capistrano 2.4.3. Когда я "ограничиваю развертывание", когда есть работающая система, поведение:

1. Приложение развернуто. Код успешно обновлен.

2. В выводе cap deploy есть это:

   • выполнение "sudo -p 'sudo password:' кластер mongrel_rails :: перезагрузка -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

Он не ждет и не проверяет, завершился ли процесс, прежде чем вызывать «start». Это известная ошибка с выдающимся патчем . Я применил патч к Mongrel Cluster, и проблема исчезла.

Answer 1

Вы можете явно указать рецептам mongrel_cluster удалить файлы pid перед началом, добавив следующее в свои рецепты capistrano:

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

Это заставляет его передавать параметр --clean в mongrel_cluster_ctl.

Я вернулся и посмотрел на один из моих рецептов развертывания и заметил, что я также изменил способ работы задачи перезапуска. Посмотрите на следующее сообщение в группе пользователей mongrel:

Обсуждение перезапуска пользователей 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

В любом случае, мои шавки запускаются до того, как предыдущая команда останова завершила их все.

сон 2.5 не является хорошим решением, если для остановки всех бегающих дворняжек требуется больше 2,5 секунд.

Кажется, необходимо:

stop && start

против

stop; start

(так работает bash, && ожидает завершения первой команды без ошибки, а ";" просто выполняет следующую команду).

Интересно, есть ли:

wait cluster_stop
then cluster_start

Answer 3

Во-первых, сузьте область тестирования, позвонив только по номеру cap deploy:restart. Возможно, вы захотите передать опцию --debug для запроса перед удаленным выполнением или опцию --dry-run, просто чтобы посмотреть, что происходит, когда вы настраиваете свои настройки.

На первый взгляд, это звучит как проблема с правами доступа к pid-файлам или процессам mongrel, но это точно сложно узнать. Несколько вещей, которые бросаются в глаза:

• переменная :runner имеет значение explicity, установленное на nil - Была ли для этого особая причина?
• Capistrano 2.4 ввел новое поведение для переменной :admin_runner . Не видя весь рецепт, это возможно связано с вашей проблемой?

  : бегун против: admin_runner (из релиз Capistrano 2.4 ) Некоторые операторы заметили, что после развертывания: setup и deploy: cleanup запустите, поскольку пользователь: runner испортил свои тщательно созданные разрешения. Я согласился, что это проблема. В этом выпуске deploy: start, deploy: stop и deploy: restart все продолжают использовать пользователя: runner при sudoing, но deploy: setup и deploy: cleanup будут использовать пользователя: admin_runner. Переменная: admin_runner не установлена, по умолчанию это означает, что эти задачи будут sudo как root, но если вы хотите, чтобы они выполнялись как: runner, просто выполните «set: admin_runner, runner».

Моя рекомендация, что делать дальше. Вручную остановить шавки и очистить PID. Запустите шавки вручную. Затем продолжайте запуск cap deploy:restart во время отладки проблемы. Повторите при необходимости.

Answer 4

Хорошая дискуссия: http://www.ruby -forum.com / topic / 139734 # 745030

Answer 5

Я не хочу быть таким простым, но похоже, что файлы pid все еще зависают при попытке запуска. Убедитесь, что дворняга остановлена ​​вручную. Очистите файлы pid вручную. Затем выполните кепку развертывания.